From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Stark <stark(at)mit(dot)edu>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, marvin_liang(at)qq(dot)com, actyzhang(at)outlook(dot)com |
Subject: | Re: pg_walinspect - a new extension to get raw WAL data and WAL stats |
Date: | 2022-03-12 11:43:31 |
Message-ID: | CALj2ACVRH-z8mZLyFkpLvY4qRhxQCqU_BLkFTtwt+TPZNhfEVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 12, 2022 at 2:09 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Mar 10, 2022 at 9:38 PM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > It seems to me too rigorous that pg_get_wal_records_info/stats()
> > reject future LSNs as end-LSN and I think WARNING or INFO and stop at
> > the real end-of-WAL is more kind to users. I think the same with the
> > restriction that start and end LSN are required to be different.
>
> In his review just yesterday, Jeff suggested this: "Don't issue
> WARNINGs or other messages for ordinary situations, like when
> pg_get_wal_records_info() hits the end of WAL." I think he's entirely
> right, and I don't think any patch that does otherwise should get
> committed. It is worth remembering that the results of queries are
> often examined by something other than a human being sitting at a psql
> terminal. Any tool that uses this is going to want to understand what
> happened from the result set, not by parsing strings that may show up
> inside warning messages.
>
> I think that the right answer here is to have a function that returns
> one row per record parsed, and each row should also include the start
> and end LSN of the record. If for some reason the WAL records return
> start after the specified start LSN (e.g. because we skip over a page
> header) or end before the specified end LSN (e.g. because we reach
> end-of-WAL) the user can figure it out from looking at the LSNs in the
> output rows and comparing them to the LSNs provided as input.
Thanks Robert. I've removed the WARNING part and added end_lsn as suggested.
Thanks Kyotaro-san, Ashutosh and Jeff for your review. I tried to
address your review comments, if not all, but many.
Here's v9 patch-set please review it further.
Regards,
Bharath Rupireddy.
Attachment | Content-Type | Size |
---|---|---|
v9-0001-pg_walinspect.patch | application/octet-stream | 26.0 KB |
v9-0001-pg_walinspect-tests.patch | application/octet-stream | 10.3 KB |
v9-0001-pg_walinspect-docs.patch | application/octet-stream | 10.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2022-03-12 14:10:30 | Re: pg_stat_statements and "IN" conditions |
Previous Message | Bharath Rupireddy | 2022-03-12 11:43:12 | Re: pg_walinspect - a new extension to get raw WAL data and WAL stats |