Re: Sync Rep v19 - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Sync Rep v19
Date
Msg-id AANLkTini5Y0xB24WrP_tBvCp5NyPfLtxsVWWE=xtbFp5@mail.gmail.com
Whole thread Raw
In response to Re: Sync Rep v19  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Sync Rep v19
List pgsql-hackers
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.

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.

+        /*
+         * 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.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Alpha4 release blockers (was Re: wrapping up this CommitFest)
Next
From: Magnus Hagander
Date:
Subject: SET TRANSACTION .. DEFERRABLE missing docs?