From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
Date: | 2024-11-04 21:00:23 |
Message-ID: | CAPpHfdtPVzf5qfMFaEmM+pWNMdUJJ7uj=g+0kU_cBQ2L3mK-9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Nov 4, 2024 at 8:04 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Mon, Nov 04, 2024 at 06:29:42AM +0200, Alexander Korotkov wrote:
> > The attached patchset contains patch 0001, which improves handling of
> > not in recovery state by usage of PromoteIsTriggered(). When
> > (PromoteIsTriggered() == false), last replay LSN is not accepted and
> > not reported in errdetail().
> >
> > 0002 contains patch finishing implicit transaction in default
> > isolation level REPEATABLE READ or higher with revised commit message.
>
> I was just catching up with this thread, and I'm still confused about
> the state of things. There are two things that are out of order for
> me, at least, after skimming through the code on HEAD (I suspect there
> is more):
> - WaitForLSNReplay() uses an initial set of checks that are duplicated
> in the main loop. This is still overcomplicated, no? Wouldn't it be
> simpler to eliminate the first of checks or just have a goto block
> with addLSNWaiter() called after the first round of checks?
> - pg_wal_replay_wait_status() returns a status based on a static
> variable that can only be accessed with the same backend as the one
> that has called the wait function. That's.. Err.. Unfriendly. Why
> being sticky with one backend for the job?
>
> 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?).
On second thought, status function is probably not so silly idea.
Unlike result of utility statement/stored procedure, it could be used
inside another function, that is one may implement custom result
handling logic on postgres server side. On contrast, if you get
something out of utility statement/stored procedure, it takes an extra
roundtrip to push it back to postgres backend.
> Based on the latest set of issues reported, it does not feel like this
> is really baked and ready for prime day, either. Perhaps it would be
> less confusing to just revert the whole and repost a more complete and
> structured implementation with an extra round of reviews? There's
> still time in this release cycle.
Reverted.
------
Regards,
Alexander Korotkov
Supabase
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-11-04 21:05:00 | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
Previous Message | Alexander Korotkov | 2024-11-04 20:56:01 | pgsql: Revert pg_wal_replay_wait() stored procedure |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-11-04 21:05:00 | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
Previous Message | Robert Haas | 2024-11-04 20:07:49 | Re: protocol-level wait-for-LSN |