Re: [HACKERS] make async slave to wait for lsn to be replayed - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id CAEepm=3Q+kWaOhPc5Vig788jzM9YZE=zvEzCieCYBQOoRsn+fg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Wed, Mar 8, 2017 at 1:58 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Tue, Mar 7, 2017 at 8:48 PM, Ivan Kartyshov
> <i.kartyshov@postgrespro.ru> wrote:
>> Rebase done.
>
> Thank you for updating the patch.
>
>>
>> Meanwhile I made some more changes.
>>
>> Changes
>> =======
>> 1) WAITLSN is now implemented as an extension called "pg_waitlsn"
>
> I've read the discussion so far but I didn't see the reason why you've
> changed it to as a contrib module. Could you tell me about that? I
> guess this feature would be more useful if provided as a core feature
> and we need to discuss about syntax as Thomas mentioned.

The problem with using functions like pg_waitlsn(‘LSN’ [, timeout in
ms]) instead of new syntax for transaction starting commands like
BEGIN TRANSACTION ... WAIT FOR ... is that it doesn't work for the
higher isolation levels.  In READ COMMITTED it's fine, because every
statement runs with its own snapshot, so when SELECT
pg_waitlsn(some_lsn) returns, the next statement will run with a
snapshot that can see the effects of some_lsn being applied.  But in
REPEATABLE READ and SERIALIZABLE, even though pg_waitlsn(some_lsn)
waits for the LSN to be applied, the next statement will run with the
snapshot from before and never see the transaction you were waiting
for.

--
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: [HACKERS] parallel index(-only) scan breaks when run without parallelism
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE