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

From Simon Riggs
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id CANP8+jL_mq4o3L99rP=ru1UrJug+_ytQupKWP-jn6+3EnqLgnw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Ivan Kartyshov <i.kartyshov@postgrespro.ru>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] make async slave to wait for lsn to be replayed  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
List pgsql-hackers
On 30 October 2017 at 17:25, Ivan Kartyshov <i.kartyshov@postgrespro.ru> wrote:

> 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.

OK, on review we want this feature in PG11

Many people think we will want to wait on a variety of things in the
future. Support for those things can come in the future when/if they
exist.

In PG11, I propose the following command, sticking mostly to Ants'
syntax, and allowing to wait for multiple events before it returns. It
doesn't hold snapshot and will not get cancelled by Hot Standby.

WAIT FOR event [, event ...] options

event is
LSN value
TIMESTAMP value

options
TIMEOUT delay
UNTIL TIMESTAMP timestamp
(we have both, so people don't need to do math, they can use whichever
they have)

We do not need "INFINITE" or "INFINITELY", obviously the default mode
for WAIT is to continue waiting until the thing you asked for happens.

I couldn't see the point of the NOWAIT option, was that a Zen joke?

WAIT can be issued on masters as well as standbys, no need to block that.

If you want this in PG11, please work on this now, including docs and
tap tests. Please submit before 1 March and I will shepherd this to
commit.

Thomas, I suggest we also do what Robert suggested elsewhere which was
to have an connection option that returns xid or lsn (or both) via the
protocol, so we can use that with the WAIT command and you can have
the overall causal consistency feature into PG11. I'll be reviewer for
that feature also if you submit.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: amul sul
Date:
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Surjective functional indexes