On 11/04/2024 18:09, Alexander Korotkov wrote:
On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas <hlinn...@iki.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)



Reply via email to