From: Ivan Kartyshov <i.kartyshov@postgrespro.ru>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: make async slave to wait for lsn to be replayed
Date: Tue, 6 Sep 2016 10:39:38 +0300
Message-ID: <19b911c0-51e1-fa12-5f73-93d30d9a4a04@postgrespro.ru> (raw)
In-Reply-To: <CAMsr+YGZrW6Ss8DKp0u7_QYTvKJXa3=J-A9vcqzeucp4Zk7=2Q@mail.gmail.com>
References: <0240c26c-9f84-30ea-fca9-93ab2df5f305@postgrespro.ru>
<CAMsr+YGZrW6Ss8DKp0u7_QYTvKJXa3=J-A9vcqzeucp4Zk7=2Q@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: i.kartyshov@postgrespro.ru, craig@2ndquadrant.com
Subject: Re: make async slave to wait for lsn to be replayed
In-Reply-To: <19b911c0-51e1-fa12-5f73-93d30d9a4a04@postgrespro.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox