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

Поиск
Список
Период
Сортировка
От Dmitry Koterov
Тема Does having pg_last_wal_replay_lsn[replica] >= pg_current_wal_insert_lsn[master] guarantee that the replica is caught up?
Дата
Msg-id CA+CZih66gSX-vZw4P+T8zUmKzFtK1n7b9FbDqNeaGZ6-tUM2DA@mail.gmail.com
обсуждение исходный текст
Ответы Re: Does having pg_last_wal_replay_lsn[replica] >= pg_current_wal_insert_lsn[master] guarantee that the replica is caught up?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Parallel Aggregates for string_agg and array_agg
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: collate not support Unicode Variation Selector