On Tue, 2011-03-01 at 15:25 +0900, Fujii Masao wrote: > On Tue, Mar 1, 2011 at 9:19 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On Mon, 2011-02-28 at 18:40 +0000, Simon Riggs wrote: > >> > SyncRepReleaseWaiters should be called when walsender exits. Otherwise, > >> > if the standby crashes while a transaction is waiting for replication, > >> > it waits infinitely. > >> > >> Will think on this. > > > > The behaviour seems correct to me:
> > If allow_standalone_primary = on then we sit and wait until we hit > > client timeout, which occurs even after last standby has gone. > > In that case, why do backends need to wait until the timeout occurs? > We can make those backends resume their transaction as soon as > the last standby has gone. No? I'm getting a little confused as to what you're asking for regarding shutdowns and WALSender disconnects. The current behaviour is that when a reply is received we attempt to wake up backends waiting for an LSN. If that reply is not received within a timeout then we just return to user anyway. You can wait forever, if you choose, by setting the timeout to 0. The WALSender deliberately does *not* wake waiting users if the standby disconnects. Doing so would break the whole reason for having sync rep in the first place. What we do is allow a potential standby to takeover the role of sync standby, if one is available. Or the failing standby can reconnect and then release waiters. If we shutdown, then we wait for the shutdown commit record to be transferred to our standby, so a normal or fast shutdown of the master always leaves all connected standbys up to date. We already do that, so sync rep doesn't touch that behaviour. If a standby is disconnected, then it doesn't receive the shutdown checkpoint record. The wait state for a commit does not persist when we shutdown and restart. Can you restate which bits of the above you think need to be changed? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
