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.163729.66343237.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [BUG] False indication in pg_stat_replication.sync_state  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: [BUG] False indication in pg_stat_replication.sync_state  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
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..148756d 100644
--- a/src/backend/replication/syncrep.c
+++ b/src/backend/replication/syncrep.c
@@ -382,7 +382,7 @@ SyncRepReleaseWaiters(void)     */    if (MyWalSnd->sync_standby_priority == 0 ||
MyWalSnd->state< WALSNDSTATE_STREAMING ||
 
-        XLogRecPtrIsInvalid(MyWalSnd->flush))
+        XLByteEQ(MyWalSnd->flush, InvalidXLogRecPtr))        return;    /*
@@ -403,7 +403,7 @@ SyncRepReleaseWaiters(void)            walsnd->sync_standby_priority > 0 &&            (priority ==
0||             priority > walsnd->sync_standby_priority) &&
 
-            !XLogRecPtrIsInvalid(walsnd->flush))
+            !XLogByteEQ(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: Amit kapila
Date:
Subject: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap [Review]
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [BUG] False indication in pg_stat_replication.sync_state