| From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Alexander Korotkov <akorotkov(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
| Date: | 2024-09-01 23:55:50 |
| Message-ID: | CAPpHfdubNR746cbxRvs8C0MmNvUTtrjWwZ=RzcB5i_4kUz+RuQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On Mon, Sep 2, 2024 at 2:28 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Sun, Sep 01, 2024 at 10:35:27PM +0300, Alexander Korotkov wrote:
> > This path hasn't changes since the patch revision when it was a
> > utility command. I agree that this doesn't look like proper path for
> > stored procedure. But I don't think src/backend/utils/adt is
> > appropriate path either, because it's not really about data type.
> > pg_wal_replay_wait() looks a good neighbor for
> > pg_wal_replay_pause()/pg_wal_replay_resume() and other WAL-related
> > functions. So, what about moving it to src/backend/access/transam?
>
> Moving the new function to xlogfuncs.c while publishing
> WaitForLSNReplay() makes sense to me.
Thank you for proposal. I like this.
Could you, please, check the attached patch?
------
Regards,
Alexander Korotkov
Supabase
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Move-pg_wal_replay_wait-to-xlogfuncs.c.patch | application/octet-stream | 5.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-09-02 00:24:55 | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
| Previous Message | Michael Paquier | 2024-09-01 23:27:50 | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2024-09-02 00:10:26 | Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible |
| Previous Message | Robert Haas | 2024-09-01 23:53:39 | Re: scalability bottlenecks with (many) partitions (and more) |