Horton

Re: Combine pg_walinspect till_end_of_wal functions with others

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-03-10T08:37:23Z
Lists: pgsql-hackers 
On Fri, 10 Mar 2023, 16:14 Michael Paquier, <michael@paquier.xyz> wrote:

> On Fri, Mar 10, 2023 at 04:04:15PM +0800, Julien Rouhaud wrote:
> > As long as we provide a sensible default value (so I guess '0/0' to
> > mean "no upper bound") and that we therefore don't have to manually
> > specify an upper bound if we don't want one I'm fine with keeping the
> > functions marked as STRICT.
>
> FWIW, using also InvalidXLogRecPtr as a shortcut to say "Don't fail,
> just do the job" is fine by me.


isn't '0/0' the same as InvalidXLogRecPtr? but my point is that we
shouldn't require to spell it explicitly, just rely on the default value.

Something like a FFF/FFFFFFFF should
> just mean the same on a fresh cluster, still it gets risky the longer
> the WAL is generated.
>

yeah, it would be handy to accept 'infinity' in that context.

>

Commits

  1. Improve a bit the tests of pg_walinspect

  2. Tweak regression test of pg_walinspect to be less collation-sensitive

  3. Rework design of functions in pg_walinspect

  4. Refactor and improve tests of pg_walinspect

  5. doc: Fix description of pg_get_wal_stats_till_end_of_wal() in pg_walinspect