Re: [BUG] False indication in pg_stat_replication.sync_state - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [BUG] False indication in pg_stat_replication.sync_state
Date
Msg-id 20121019.174631.105753447.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [BUG] False indication in pg_stat_replication.sync_state  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: [BUG] False indication in pg_stat_replication.sync_state
List pgsql-hackers
Ouch! I'm sorry to have sent truly buggy version, please abandon
v2 patch sent just before.

Added include "access/transam.h" to syncrep.c and corrected the
name of XLByteEQ.

> Thank you for comment.
> 
> > > I think this patch should be applied for 9.2.2 and 9.1.7.
> > 
> > Looks good to me, though I don't think the source code comment needs
> > to be updated in the way the patch does.
> 
> Ok, the patch for walsender.c becomes 1 liner, quite simple.
> 
> However, I've forgotten to treat other three portions in
> walsender.c and syncrep.c also does XLogRecPtrIsInvalid(<XLogPtr
> which comes from WAL receiver>).  This new patch includes the
> changes for them.
> 
> By the way, XLogRecPtrIsInvliad() seems to be used also in
> gist.c, gistget.c, gistvacuum.c, visibilitymap.c, clog.c, slru.c,
> xlog.c.
> 
> In these files, LSN's fed to XLogRecPtrIsInvalid() looks to be
> *valid* start point of WAL records, but I'm not sure of that.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/replication/syncrep.c b/src/backend/replication/syncrep.c
index 088f7b6..6caf586 100644
--- a/src/backend/replication/syncrep.c
+++ b/src/backend/replication/syncrep.c
@@ -46,6 +46,7 @@#include <unistd.h>#include "access/xact.h"
+#include "access/transam.h"#include "miscadmin.h"#include "replication/syncrep.h"#include "replication/walsender.h"
@@ -382,7 +383,7 @@ SyncRepReleaseWaiters(void)     */    if (MyWalSnd->sync_standby_priority == 0 ||
MyWalSnd->state< WALSNDSTATE_STREAMING ||
 
-        XLogRecPtrIsInvalid(MyWalSnd->flush))
+        XLByteEQ(MyWalSnd->flush, InvalidXLogRecPtr))        return;    /*
@@ -403,7 +404,7 @@ SyncRepReleaseWaiters(void)            walsnd->sync_standby_priority > 0 &&            (priority ==
0||             priority > walsnd->sync_standby_priority) &&
 
-            !XLogRecPtrIsInvalid(walsnd->flush))
+            !XLByteEQ(walsnd->flush, InvalidXLogRecPtr))        {            priority = walsnd->sync_standby_priority;
          syncWalSnd = walsnd;
 
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 064ddd5..6c27449 100644
--- a/src/backend/replication/walsender.c
+++ b/src/backend/replication/walsender.c
@@ -1559,14 +1559,14 @@ pg_stat_get_wal_senders(PG_FUNCTION_ARGS)             * which always returns an invalid flush
location,as an             * asynchronous standby.             */
 
-            sync_priority[i] = XLogRecPtrIsInvalid(walsnd->flush) ?
+            sync_priority[i] = XLByteEQ(walsnd->flush, InvalidXLogRecPtr) ?                0 :
walsnd->sync_standby_priority;           if (walsnd->state == WALSNDSTATE_STREAMING &&
walsnd->sync_standby_priority> 0 &&                (priority == 0 ||                 priority >
walsnd->sync_standby_priority)&&
 
-                !XLogRecPtrIsInvalid(walsnd->flush))
+                !XLByteEQ(walsnd->flush, InvalidXLogRecPtr))            {                priority =
walsnd->sync_standby_priority;               sync_standby = i; 

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [BUG] False indication in pg_stat_replication.sync_state
Next
From: Kohei KaiGai
Date:
Subject: Re: [v9.3] Row-Level Security