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.
>
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 |