Re: [HACKERS] make async slave to wait for lsn to be replayed
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Дата | |
Msg-id | d1303584-b763-446c-9409-f4516118219f@iki.fi обсуждение исходный текст |
Ответ на | Re: [HACKERS] make async slave to wait for lsn to be replayed (Alexander Korotkov <aekorotkov@gmail.com>) |
Список | pgsql-hackers |
On 11/04/2024 18:09, Alexander Korotkov wrote: > On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas <hlinnaka@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)
В списке pgsql-hackers по дате отправления: