Horton

Re: pgsql: Implement pg_wal_replay_wait() stored procedure

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>, Heikki Linnakangas <hlinnaka@iki.fi>, Pavel Borisov <pashkin.elfe@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-04T19:04:25Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert pg_wal_replay_wait() stored procedure

  2. Add 'no_error' argument to pg_wal_replay_wait()

  3. Refactor WaitForLSNReplay() to return the result of waiting

  4. Make WaitForLSNReplay() issue FATAL on postmaster death

  5. Move LSN waiting declarations and definitions to better place

  6. Update oid for pg_wal_replay_wait() procedure

  7. Move pg_wal_replay_wait() to xlogfuncs.c

  8. Implement pg_wal_replay_wait() stored procedure

On Mon, Nov 4, 2024 at 4:19 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> On 2024-Nov-04, Alexander Korotkov wrote:
>
> > On Mon, Nov 4, 2024 at 8:04 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> > > Using output parameters in a procedure is something I did not recall.
> > > Based on your point about not using a function due your argument based
> > > on the snapshots, let's just use that and forget about the status
> > > function entirely (please?).
> >
> > Please, check [1].  Usage of output parameters is a bit awkward too,
> > because you need to pass some value in there.  And more importantly,
> > usage of output parameters also causes snapshot problem, as it causes
> > another snapshot to be held.
>
> I wonder if it would be better to go back to the original idea of using
> special DDL syntax rather than a procedure.  It seems we've been piling
> up hacks to get around the behavior of procedures, and we seem to have
> grown one more to handle repeatable read transactions.
>
> It's looking to me like there's just too much cruft in the quest to
> avoid having to reach consensus on new syntax.  This might be a mistake.
> Is it possible to backtrack on that decision?

Before committing pg_wal_replay_wait() I was under impression that
stored procedure would require the same amount of efforts than utility
statement to make backend "snapshot-less".  However, it appears that
if we have implicit REPEATABLE READ transaction, stored procedure
needs more efforts.  That makes the whole decision, at least,
questionable.

------
Regards,
Alexander Korotkov
Supabase