On Sat, 2011-03-05 at 16:13 +0900, Fujii Masao wrote: > On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > Almost-working patch attached for the above feature. Time to stop for > > the day. Patch against current repo version. > > > > Current repo version attached here also (v20), which includes all fixes > > to all known technical issues, major polishing etc.. > > Thanks for the patch. Now the code about the wait list looks very > simpler than before! Here are the comments: > > @@ -1337,6 +1352,31 @@ pg_stat_get_wal_senders(PG_FUNCTION_ARGS) > <snip> > + if (walsnd->pid != 0 && walsnd->state == WALSNDSTATE_STREAMING) > + { > + sync_priority[i] = walsnd->sync_standby_priority; > > This always reports the priority of walsender in CATCHUP state as 0. > I don't think that priority needs to be reported as 0.
Cosmetic change. We can do this, yes. > When new standby which has the same priority as current sync standby > connects, that new standby can switch to new sync one even though > current one is still running. This happens when the index of WalSnd slot > which new standby uses is ahead of that which current one uses. People > don't expect such an unexpected switchover, I think. It is documented that the selection of standby from a set of similar priorities is indeterminate. Users don't like it, they can change it. > + /* > + * Assume the queue is ordered by LSN > + */ > + if (XLByteLT(walsndctl->lsn, proc->waitLSN)) > + return numprocs; > > The code to ensure the assumption needs to be added. Yes, just need to add the code for traversing list backwards. -- 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