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

From Heikki Linnakangas
Subject Re: [BUG] False indication in pg_stat_replication.sync_state
Date
Msg-id 50AFB9C1.5000806@vmware.com
Whole thread Raw
In response to Re: [BUG] False indication in pg_stat_replication.sync_state  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 23.11.2012 19:55, Tom Lane wrote:
> Heikki Linnakangas<hlinnakangas@vmware.com>  writes:
>> Committed, thanks.
>
> Doesn't seem to have been pushed to master?

On purpose. Per commit message:

> 9.3 doesn't have this problem because XLogRecPtr is now a single 64-bit
> integer, so XLogRecPtrIsInvalid() does the right thing. Apply to 9.2, and
> 9.1 where pg_stat_replication view was introduced.

I considered applying it to master anyway, just to keep the branches in 
sync. But XLogRecPtrIsInvalid(var) seems slightly more readable than 
XLByteEQ(var, InvalidXLogRecPtr), so I decided not to.

- Heikki



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [BUG] False indication in pg_stat_replication.sync_state
Next
From: Josh Kupershmidt
Date:
Subject: Re: Suggestion for --truncate-tables to pg_restore