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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: a(dot)akenteva(at)postgrespro(dot)ru, a(dot)korotkov(at)postgrespro(dot)ru, i(dot)kartyshov(at)postgrespro(dot)ru, amit(dot)kapila16(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Date: 2020-04-09 07:11:07
Message-ID: 20200409.161107.580344062273684114.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in
> Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru> writes:
> > I'd like to hear others' opinions on the syntax as well.
>
> Pardon me for coming very late to the party, but it seems like there are
> other questions that ought to be answered before we worry about any of
> this. Why is this getting grafted onto BEGIN/START TRANSACTION in the
> first place? It seems like it would be just as useful as a separate
> command, if not more so. You could always start a transaction just
> after waiting. Conversely, there might be reasons to want to wait
> within an already-started transaction.
>
> If it could survive as a separate command, then I'd humbly suggest
> that it requires no grammar work at all. You could just invent one
> or more functions that take suitable parameters.

The rationale for not being a fmgr function is stated in the following
comments.

https://www.postgresql.org/message-id/CAEepm%3D0V74EApmfv%3DMGZa24Ac_pV1vGrp3Ovnv-3rUXwxu9epg%40mail.gmail.com
| because it doesn't work for our 2 higher isolation levels as
| mentioned."

https://www.postgresql.org/message-id/CA%2BTgmob-aG3Lqh6OpvMDYTNR5eyq94VugyEejyk7pLhE9uwnyA%40mail.gmail.com

| IMHO, trying to do this using a function-based interface is a really
| bad idea for exactly the reasons you mention. I don't see why we'd
| resist the idea of core syntax here; transactions are a core part of
| PostgreSQL.

It seemed to me that they were suggested it to be in a part of BEGIN
command, but the next proposed patch implemented "WAIT FOR" command
for uncertain reasons to me. I don't object to the isolate command if
it is useful than a part of BEGIN command.

By the way, for example, pg_current_wal_lsn() is a volatile function
and repeated calls within a SERIALIZABLE transaction can return
different values.

If there's no necessity for this feature to be a core command, I think
I would like to be it a function.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-04-09 07:14:01 Re: adding partitioned tables to publications
Previous Message Amit Kapila 2020-04-09 07:03:57 Re: Vacuum o/p with (full 1, parallel 0) option throwing an error