Re: Combine pg_walinspect till_end_of_wal functions with others
| От | Julien Rouhaud |
|---|---|
| Тема | Re: Combine pg_walinspect till_end_of_wal functions with others |
| Дата | |
| Msg-id | CAOBaU_aNRDuh2430o5nKRhbJzoK3pkV_7QQ6x+vQKbksn1EcjQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Combine pg_walinspect till_end_of_wal functions with others (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Combine pg_walinspect till_end_of_wal functions with others
|
| Список | 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 по дате отправления: