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 |
Message-ID: | d1303584-b763-446c-9409-f4516118219f@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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;
> CALL
> 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 (https://neon.tech)
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 |