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: