(too bad the history has been removed to keep context)
On Fri, 8 May 2020 15:02:26 +0500
godjan • <g0dj4n@gmail.com> wrote:
> I got it, thank you.
> Can you recommend what to use to determine which quorum standby should be
> promoted in such case? We planned to use pg_last_wal_receive_lsn() to
> determine which has fresh data but if it returns the beginning of the segment
> on both replicas we can’t determine which standby confirmed that write
> transaction to disk.
Wait, pg_last_wal_receive_lsn() only decrease because you killed your standby.
pg_last_wal_receive_lsn() returns the value of walrcv->flushedUpto. The later
is set to the beginning of the segment requested only during the first
walreceiver startup or a timeline fork:
/*
* If this is the first startup of walreceiver (on this timeline),
* initialize flushedUpto and latestChunkStart to the starting point.
*/
if (walrcv->receiveStart == 0 || walrcv->receivedTLI != tli)
{
walrcv->flushedUpto = recptr;
walrcv->receivedTLI = tli;
walrcv->latestChunkStart = recptr;
}
walrcv->receiveStart = recptr;
walrcv->receiveStartTLI = tli;
After a primary loss, as far as the standby are up and running, it is fine
to use pg_last_wal_receive_lsn().
Why do you kill -9 your standby? Whay am I missing? Could you explain the
usecase you are working on to justify this?
Regards,