| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "satyanarlapuram(at)gmail(dot)com" <satyanarlapuram(at)gmail(dot)com>, "marvin_liang(at)qq(dot)com" <marvin_liang(at)qq(dot)com>, "actyzhang(at)outlook(dot)com" <actyzhang(at)outlook(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
| Subject: | Re: pg_walinspect - a new extension to get raw WAL data and WAL stats |
| Date: | 2021-09-10 14:29:48 |
| Message-ID: | CALj2ACWTrjCckDTq=5doz-DNhd518S9OjXAYQrPfEO-rLb+mbw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 10, 2021 at 7:21 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Sep 09, 2021 at 10:49:46PM +0000, Bossart, Nathan wrote:
> > +1
>
> A backend approach has the advantage that you can use the proper locks
> to make sure that a segment is not recycled or removed by a concurrent
> checkpoint, so that would be reliable.
Thanks for sharing your thoughts. IMO, using locks for showing WAL
stats isn't a good way, because these new functions may block the
checkpointer from removing/recycling the WAL files. We don't want to
do that. If at all, user has asked stats of an LSN/range of LSNs if
it is/they are available in the pg_wal directory, we provide the info
otherwise we can throw warnings/errors. This behaviour is pretty much
in sycn with what pg_waldump does right now.
And, some users may not need these new functions at all, so in such
cases going with an extension way makes it more usable.
Regards,
Bharath Rupireddy.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amul Sul | 2021-09-10 14:36:30 | Re: [Patch] ALTER SYSTEM READ ONLY |
| Previous Message | Julien Rouhaud | 2021-09-10 14:19:29 | Re: parallelizing the archiver |