Does having pg_last_wal_replay_lsn[replica] >= pg_current_wal_insert_lsn[master] guarantee that the replica is caught up?

From: Dmitry Koterov <dmitry(dot)koterov(at)gmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Does having pg_last_wal_replay_lsn[replica] >= pg_current_wal_insert_lsn[master] guarantee that the replica is caught up?
Date: 2022-08-03 01:57:41
Message-ID: CA+CZih66gSX-vZw4P+T8zUmKzFtK1n7b9FbDqNeaGZ6-tUM2DA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-08-03 02:02:08 Re: collate not support Unicode Variation Selector
Previous Message David Rowley 2022-08-03 01:42:47 Re: Parallel Aggregates for string_agg and array_agg