Re: [HACKERS] make async slave to wait for lsn to be replayed

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Ivan Kartyshov <i(dot)kartyshov(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Date: 2018-01-22 23:21:00
Message-ID: 20180122232100.GZ2416@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings Ivan,

* Ivan Kartyshov (i(dot)kartyshov(at)postgrespro(dot)ru) wrote:
> Ants Aasma писал 2017-10-26 17:29:
> >On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov
> ><i(dot)kartyshov(at)postgrespro(dot)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.

There were a few different suggestions made, but somehow this thread
ended up in Needs Review again while still having LSNs. I've changed it
back to Waiting for Author since it seems pretty unlikely that using LSN
is going to be acceptable based on the feedback.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-01-22 23:22:05 Re: [HACKERS] A design for amcheck heapam verification
Previous Message Stephen Frost 2018-01-22 22:58:18 Re: [HACKERS] Subscription code improvements