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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: [HACKERS] make async slave to wait for lsn to be replayed
Дата
Msg-id CAEepm=3Q+kWaOhPc5Vig788jzM9YZE=zvEzCieCYBQOoRsn+fg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] make async slave to wait for lsn to be replayed  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: [HACKERS] parallel index(-only) scan breaks when run without parallelism
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE