On Fri, 2011-03-04 at 16:57 +0900, Fujii Masao wrote: > On Wed, Mar 2, 2011 at 11:30 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > > On Wed, Mar 2, 2011 at 8:22 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > >> 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 there is potential standby when synchronous standby has gone, I agree > > that it's not good idea to release the waiting backends soon. In this case, > > those backends should wait for next synchronous standby. > > > > On the other hand, if there is no potential standby, I think that the > > waiting > > backends should not wait for the timeout and should wake up as soon as > > synchronous standby has gone. Otherwise, those backends suspend for > > a long time (i.e., until the timeout expires), which would decrease the > > high-availability, I'm afraid. > > > > Keeping those backends waiting for the failed standby to reconnect is an > > idea. But this looks like the behavior for "allow_standalone_primary = off". > > If allow_standalone_primary = on, it looks more natural to make the > > primary work alone without waiting the timeout. > > Also I think that the waiting backends should be released as soon as the > last synchronous standby switches to asynchronous mode. Since there is > no standby which is planning to reconnect, obviously they no longer need > to wait.
I've not done this, but we could. It can't run in a WALSender, so this code would need to live in either WALWriter or BgWriter. -- 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