Re: Sync Rep v19

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