From: Ivan Kartyshov <i.kartyshov@postgrespro.ru>
To: pgsql-hackers@postgresql.org
Subject: Re: make async slave to wait for lsn to be replayed
Date: Mon, 30 Oct 2017 20:25:18 +0300
Message-ID: <de402dc80e39c358dedf174c13bb5226@postgrespro.ru> (raw)
In-Reply-To: <CA+CSw_uW2yVMMvQ8S2hAfbobXSDhCF0uBZ3zjYL650Z=-0PkFQ@mail.gmail.com>
References: <0240c26c-9f84-30ea-fca9-93ab2df5f305@postgrespro.ru>
<CAEepm=105OCnhe9cAdYp0Vy1b2VmQFX6n9qM+nx70GXUKgjF9A@mail.gmail.com>
<c585d9a0-5bda-778e-e628-dd30959d71d3@postgrespro.ru>
<CAPpHfdvUnqY8TTwZ4gMOcwY+3S+N=07gpuL61p41E6SdAetvCg@mail.gmail.com>
<abcff0b4e3ce1c2a4d14f54e7031dc15@postgrespro.ru>
<CA+CSw_uW2yVMMvQ8S2hAfbobXSDhCF0uBZ3zjYL650Z=-0PkFQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Ants Aasma писал 2017-10-26 17:29:
> On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov
> <i.kartyshov@postgrespro.ru> wrote:
>> Ants Aasma писал 2017-09-26 13:00:
>>>
>>> Exposing this interface as WAITLSN will encode that visibility order
>>> matches LSN order. This removes any chance of fixing for example
>>> visibility order of async/vs/sync transactions. Just renaming it so
>>> the token is an opaque commit visibility token that just happens to
>>> be
>>> a LSN would still allow for progress in transaction management. For
>>> example, making PostgreSQL distributed will likely want timestamp
>>> and/or vector clock based visibility rules.
>>
>>
>> I'm sorry I did not understand exactly what you meant.
>> Please explain this in more detail.
>
> Currently transactions on the master become visible when xid is
> removed from proc array. This depends on the order of acquiring
> ProcArrayLock, which can happen in a different order from inserting
> the commit record to wal. Whereas on the standby the transactions will
> become visible in the same order that commit records appear in wal.
> The difference can be quite large when transactions are using
> different values for synchronous_commit. Fixing this is not easy, but
> we may want to do it someday. IIRC CSN threads contained more
> discussion on this topic. If we do fix it, it seems likely that what
> we need to wait on is not LSN, but some other kind of value. If the UI
> were something like "WAITVISIBILITY token", then we can later change
> the token to something other than LSN.
>
> Regards,
> Ants Aasma
It sounds reasonable. I can offer the following version.
WAIT LSN lsn_number;
WAIT LSN lsn_number TIMEOUT delay;
WAIT LSN lsn_number INFINITE;
WAIT LSN lsn_number NOWAIT;
WAIT [token] wait_value [option];
token - [LSN, TIME | TIMESTAMP | CSN | XID]
option - [TIMEOUT | INFINITE | NOWAIT]
Ready to listen to your suggestions.
--
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
Subject: Re: make async slave to wait for lsn to be replayed
In-Reply-To: <de402dc80e39c358dedf174c13bb5226@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