Re: Combine pg_walinspect till_end_of_wal functions with others

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Combine pg_walinspect till_end_of_wal functions with others
Date: 2023-03-10 08:37:23
Message-ID: CAOBaU_aNRDuh2430o5nKRhbJzoK3pkV_7QQ6x+vQKbksn1EcjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 10 Mar 2023, 16:14 Michael Paquier, <michael(at)paquier(dot)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.

>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuya Watari 2023-03-10 08:38:46 Re: [PoC] Reducing planning time when tables have many partitions
Previous Message Michael Paquier 2023-03-10 08:16:53 Re: Compilation error after redesign of the archive modules