On Wed, Mar 1, 2023 at 1:00 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> In a recent discussion [1], Michael Paquier asked if we can combine
> pg_walinspect till_end_of_wal functions with other functions
> pg_get_wal_records_info and pg_get_wal_stats. The code currently looks
> much duplicated and the number of functions that pg_walinspect exposes
> to the users is bloated. The point was that the till_end_of_wal
> functions determine the end LSN and everything else that they do is
> the same as their counterpart functions. Well, the idea then was to
> keep things simple, not clutter the APIs, have better and consistent
> user-inputted end_lsn validations at the cost of usability and code
> redundancy. However, now I tend to agree with the feedback received.
>
> I'm attaching a patch doing the $subject with the following behavior:
> 1. If start_lsn is NULL, error out/return NULL.
> 2. If end_lsn isn't specified, default to NULL, then determine the end_lsn.
> 3. If end_lsn is specified as NULL, then determine the end_lsn.
> 4. If end_lsn is specified as non-NULL, then determine if it is
> greater than start_lsn if yes, go ahead do the job, otherwise error
> out.
>
> Another idea is to convert till_end_of_wal flavors to SQL-only
> functions and remove the c code from pg_walinspect.c. However, I
> prefer $subject and completely remove till_end_of_wal flavors for
> better usability in the long term.
>
> Thoughts?
>
> [1] https://www.postgresql.org/message-id/CALj2ACV-WBN%3DEUgUPyYOGitp%2Brn163vMnQd%3DHcWrnKt-uqFYFA%40mail.gmail.com
Needed a rebase due to 019f8624664dbf1e25e2bd721c7e99822812d109.
Attaching v2 patch. Sorry for the noise.
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
