Does having pg_last_wal_replay_lsn[replica] >= pg_current_wal_insert_lsn[master] guarantee that the replica is caught up? - Mailing list pgsql-hackers

From Dmitry Koterov
Subject Does having pg_last_wal_replay_lsn[replica] >= pg_current_wal_insert_lsn[master] guarantee that the replica is caught up?
Date
Msg-id CA+CZih66gSX-vZw4P+T8zUmKzFtK1n7b9FbDqNeaGZ6-tUM2DA@mail.gmail.com
Whole thread Raw
Responses Re: Does having pg_last_wal_replay_lsn[replica] >= pg_current_wal_insert_lsn[master] guarantee that the replica is caught up?
List pgsql-hackers
Hi.

Suppose on master, I run a multi-query using PQexec and save the value returned by pg_current_wal_insert_lsn:

master_lsn = query(master, "INSERT INTO some VALUES (...); SELECT pg_current_wal_insert_lsn()")

Then I run a PQexec query on a replica and save the value returned by pg_last_wal_replay_lsn:

replica_lsn = query(replica, "SELECT pg_last_wal_replay_lsn()")

The question to experts in PG internals: is it guaranteed that, as long as replica_lsn >= master_lsn (GREATER OR EQUAL, not just greater), then a subsequent read from replica will always return me the inserted record (i.e. the replica is up to date), considering noone updates/deletes in that table?

I'm asking, because according to some hints in the docs, this should be true. But for some reason, we have to use "greater" (not "greater or equals") condition in the real code, since with just ">=" the replica doesn't sometimes read the written data.

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Parallel Aggregates for string_agg and array_agg
Next
From: Thomas Munro
Date:
Subject: Re: collate not support Unicode Variation Selector