Re: make async slave to wait for lsn to be replayed

On 08/31/2016 05:54 PM, Craig Ringer wrote:
> How do you get the commit LSN to watch for? Grab
> pg_current_xlog_insert_location() just after the commit and figure
> that replaying to that point guarantees you get the commit?

That's the point, it was created in order to provide the cosistent view
of data between master and replica. You almost guessed, I used
GetXLogReplayRecPtr() right after LSN was physically replayed on downstream.

> Some time ago[1] I raised the idea of reporting commit LSN on the wire
> to clients. That didn't go anywhere due to compatibility and security
> concerns. I think those were resolvable, but it wasn't enough of a
> priority to push hard on at the time. A truly "right" solution has to
> wait for a protocol bump, but I think good-enough solutions are
> possible now. So you might want to read that thread.

Thank you for pointing to your thread, it was very informative!
It seems that you have solved the very similar problem.

> It also mentions hesitations about exposing LSN to clients even more.
> I think we're *way* past that now - we have replication origins and
> replication slots relying on it, it's exposed in a pg_lsn datatype, a
> bunch of views expose it, etc. But it might be reasonable to ask
> "should the client instead be expected to wait for the confirmed
> commit of a 64-bit epoch-extended xid, like that returned by
> txid_current()?" . One advantage of using xid is that you can get it
> while you're still in the xact, so there's no race between commit and
> checking the lsn after commit.

That sounds reasonable, but I dont think it will give us any
considerable benefits. But I`ll work out this variant.

> Are you specifically trying to ensure "this commit has replayed on the
> replica before we run queries on it" ? Or something else?

Yes you are right, I want to ensure data consistency on downstream
before running queries on it. Our clients would use it as a part of
background worker and maybe directly in apps too.

---
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company