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

From Kyotaro Horiguchi
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id 20200408.100945.375702947246835193.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed  (Anna Akenteva <a.akenteva@postgrespro.ru>)
List pgsql-hackers
At Wed, 8 Apr 2020 02:52:55 +0300, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote in 
> On Wed, Apr 8, 2020 at 2:14 AM Kartyshov Ivan
> <i.kartyshov@postgrespro.ru> wrote:
> > On 2020-04-08 00:27, Tom Lane wrote:
> > > Alexander Korotkov <akorotkov@postgresql.org> writes:
> > »   WAIT FOR LSN lsn [ TIMEOUT timeout ]
> > >
> > > This seems like a really carelessly chosen syntax —- *three* new
> > > keywords, when you probably didn't need any.  Are you not aware that
> > > there is distributed overhead in the grammar for every keyword?
> > > Plus, each new keyword carries the risk of breaking existing
> > > applications, since it no longer works as an alias-not-preceded-by-AS.
> > >
> >
> > To avoid creating new keywords, we could change syntax in the following
> > way:
> > WAIT FOR => DEPENDS ON
> 
> Looks OK for me.
> 
> > LSN => EVENT
> 
> I think it's too generic.  Not every event is lsn.  TBH, lsn is not
> event at all :)
> 
> I wonder is we can still use word lsn, but don't use keyword for that.
> Can we take arbitrary non-quoted literal there and check it later?
> 
> > TIMEOUT => WITH INTERVAL
> 
> I'm not yet sure about this.  Probably there are better options.

How about something like the follows.

BEGIN AFTER ColId Sconst
BEGIN FOLOWING ColId Sconst

UNTIL <absolute time>;
LIMIT BY <interval>;
WITHIN Iconst;

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Use compiler intrinsics for bit ops in hash
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Allow users to limit storage reserved by replication slots