Re: Strange decreasing value of pg_last_wal_receive_lsn()

(too bad the history has been removed to keep context)

On Fri, 8 May 2020 15:02:26 +0500
godjan •  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,