On Sun, Oct 31, 2021 at 4:29 PM Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
On 2021-10-29 13:22:56 -0400, Oleg Serov wrote: > We are using a master/slave replication system where we perform writes on > master and use replication to offload reads. > > However, sometimes we have a replication lag of a few seconds and as a result, > after the update, the change is not yet available on the replica. > > Is there a way to get XLOG position to which specific update query will be > written? That way we can check if our replica caught up with changes and it is > safe to read it from. Can it be done using SQL functions? Can I get that > information from query protocol?
I think I would prefer a more direct approach:
If you know what you've written, can't you just check whether the replica has the new value(s)?
The simplest answer: One thread on a single process on a server knows about it. Now another thread on another process/other server does not know about it.
If not, an alternative could be a table which contains a simple counter or timestamp:
begin; (lots of updates ...) commit; begin; update counter set c = c + 1 returning c; -- save this as c_current commit;
Select c from counter on the replica in a loop until c >= c_current.
Why invent something totally new when XLOG position is already used for replication by postgres? What are the benefits of it?
hp
-- _ | Peter J. Holzer | Story must make more sense than reality. |_|_) | | | | | hjp@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!"
