Re: Combine pg_walinspect till_end_of_wal functions with others - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Combine pg_walinspect till_end_of_wal functions with others
Date
Msg-id CAOBaU_aNRDuh2430o5nKRhbJzoK3pkV_7QQ6x+vQKbksn1EcjQ@mail.gmail.com
Whole thread Raw
In response to Re: Combine pg_walinspect till_end_of_wal functions with others  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Combine pg_walinspect till_end_of_wal functions with others  (Michael Paquier <michael@paquier.xyz>)
List 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. 

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Compilation error after redesign of the archive modules
Next
From: Yuya Watari
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions