From: | Sébastien Lardière <sebastien(at)lardiere(dot)net> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Timeline ID hexadecimal format |
Date: | 2023-02-01 16:54:43 |
Message-ID: | c6bfa979-d6bd-e2cf-f975-116a9b4229b9@lardiere.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31/01/2023 20:16, Greg Stark wrote:
> The fact that the *filename* has it encoded in hex is an
> implementation detail and really gets exposed here because it's giving
> you the underlying system error that caused the problem.
It's an implementation detail, but an exposed detail, so, people refer
to the filename to find the timeline ID (That's why it happened to me)
> The confusion
> only arises when the two are juxtaposed. A hint or something just in
> that case might be enough?
>
>
Thanks, i got your point.
Note that my proposal was to remove the ambiguous notation which
happen in some case (as in 11 <-> 17). A hint is useless in most of the
case, because there is no ambiguous. That's why i though format
hexadecimal everywhere.
At least, can I propose to improve the documentation to expose the fact
that the timeline ID is exposed in hexadecimal in filenames but must be
used in decimal in recovery_target_timeline and pg_waldump ?
regards,
--
Sébastien
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2023-02-01 16:57:45 | Re: About PostgreSQL Core Team |
Previous Message | Tom Lane | 2023-02-01 16:47:23 | Re: RLS makes COPY TO process child tables |