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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Kartyshov Ivan <i(dot)kartyshov(at)postgrespro(dot)ru>, Euler Taveira <euler(at)eulerto(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Peter Smith <smithpb2250(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: 2024-04-11 15:47:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 11/04/2024 18:09, Alexander Korotkov wrote:
> On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> On 07/04/2024 00:52, Alexander Korotkov wrote:
>>> * At first, we check that pg_wal_replay_wait() is called in a non-atomic
>>> * context. That is, a procedure call isn't wrapped into a transaction,
>>> * another procedure call, or a function call.
>>> *
>> It's pretty unfortunate to have all these restrictions. It would be nice
>> to do:
>> select pg_wal_replay_wait('0/1234'); select * from foo;
> This works for me, except that it needs "call" not "select".
> # call pg_wal_replay_wait('0/1234'); select * from foo;
> i
> ---
> (0 rows)

If you do that from psql prompt, it works because psql parses and sends
it as two separate round-trips. Try:

psql postgres -p 5433 -c "call pg_wal_replay_wait('0/4101BBB8'); select 1"
ERROR: pg_wal_replay_wait() must be only called in non-atomic context
DETAIL: Make sure pg_wal_replay_wait() isn't called within a
transaction, another procedure, or a function.

>> This assumption that PortalRunUtility() can tolerate us popping the
>> snapshot sounds very fishy. I haven't looked at what's going on there,
>> but doesn't sound like a great assumption.
> This is what PortalRunUtility() says about this.
> /*
> * Some utility commands (e.g., VACUUM) pop the ActiveSnapshot stack from
> * under us, so don't complain if it's now empty. Otherwise, our snapshot
> * should be the top one; pop it. Note that this could be a different
> * snapshot from the one we made above; see EnsurePortalSnapshotExists.
> */
> So, if the vacuum pops a snapshot when it needs to run without a
> snapshot, then it's probably OK for other utilities. But I agree this
> decision needs some consensus.

Ok, so it's at least somewhat documented that it's fine.

>> Overall, this feature doesn't feel quite ready for v17, and IMHO should
>> be reverted. It's a nice feature, so I'd love to have it fixed and
>> reviewed early in the v18 cycle.
> Thank you for your review. I've reverted this. Will repost this for early v18.

Thanks Alexander for working on this.

Heikki Linnakangas
Neon (

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-04-11 16:19:09 Re: Table AM Interface Enhancements
Previous Message Imseih (AWS), Sami 2024-04-11 15:37:23 Re: allow changing autovacuum_max_workers without restarting