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