Re: Sync Rep v17

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com>
Subject: Re: Sync Rep v17
Date: 2011-03-01 08:29:01
Message-ID: 1298968141.12992.3235.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2011-03-01 at 16:28 +0900, Fujii Masao wrote:
> On Tue, Mar 1, 2011 at 3:39 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >> PREPARE TRANSACTION and ROLLBACK PREPARED should wait for
> >> replication as well as COMMIT PREPARED?
> >
> > PREPARE - Yes
> > ROLLBACK - No
> >
> > Further discussion welcome
>
> If we don't make ROLLBACK PREPARED wait for replication, we might need to
> issue ROLLBACK PREPARED to new master again after failover, even if we've
> already received a success indication of ROLLBACK PREPARED from old master.
> This looks strange to me because, OTOH, in simple COMMIT/ROLLBACK case,
> we don't need to issue that to new master again after failover.

OK

> >> What if fast shutdown is requested while RecordTransactionCommit
> >> is waiting in SyncRepWaitForLSN? ISTM fast shutdown cannot complete
> >> until replication has been successfully done (i.e., until at least one
> >> synchronous standby has connected to the master especially if
> >> allow_standalone_primary is disabled). Is this OK?
> >
> > A "behaviour" - important, though needs further discussion.
>
> One of the scenarios which I'm concerned is:
>
> 1. The primary is running with allow_standalone_primary = on.
> 2. While some backends are waiting for replication, the user requests
> fast shutdown.
> 3. Since the timeout expires, those backends stop waiting and return the success
> indication to the client (but not replicated to the standby).
> 4. Since there is no backend waiting for replication, fast shutdown completes.
> 5. The clusterware like pacemaker detects the death of the primary and
> triggers the
> failover.
> 6. New primary doesn't have some transactions committed to the client, i.e.,
> transaction lost happens!!
>
> To avoid such a transaction lost, we should prevent the primary from
> returning the
> success indication to the client while fast shutdown is being executed, even if
> allow_standalone_primary is enabled, I think. Thought?

Walsenders don't shutdown until after they have sent the shutdown
checkpoint.

We could make them wait for the reply from the standby at that point.

I'll think some more, not convinced yet.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Urbański 2011-03-01 08:47:43 Re: pl/python tracebacks
Previous Message Simon Riggs 2011-03-01 08:21:14 Re: Sync Rep v17