On Sat, 2011-03-05 at 16:13 +0900, Fujii Masao wrote:
> On Sat, Mar 5, 2011 at 7:28 AM, Simon Riggs <simon@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
