| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | mats(dot)kindahl(at)gmail(dot)com |
| Cc: | japinli(at)hotmail(dot)com, suryapoondla4(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_rewind does not rewind diverging timelines |
| Date: | 2026-06-02 05:29:18 |
| Message-ID: | 20260602.142918.705919985422427526.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
At Tue, 2 Jun 2026 04:13:45 +0200, Mats Kindahl <mats(dot)kindahl(at)gmail(dot)com> wrote in
> If two servers go through the same sequence, e.g., start at the same
> timeline, does a promote, and write same length but different data
> (e.g., add a line to a table, but with different contents), they might
> end up with same TLI, same LSN, but different pg_promote calls, and
> different database contents, hence it is not possible to distinguish
> them.
Thanks for the explanation.
When I described UUIDs as somewhat heavyweight, I was thinking less
about the runtime overhead and more about operational convenience for
humans. Your clarification that the UUID only lives in the timeline
history file addresses most of the implementation concerns I had in
mind.
My earlier suggestion was based on the assumption that two independent
histories ending up with the same TLI and switchpoint LSN would be
rare enough to be ignored in practice. If the goal is to rule out that
possibility entirely rather than merely make it extremely unlikely,
then I can see why some additional identifier would be needed.
In that context, a UUID certainly seems like a viable option.
Regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2026-06-02 05:46:22 | Re: Row pattern recognition |
| Previous Message | Michael Paquier | 2026-06-02 05:27:32 | Re: injection_points: Switch wait/wakeup to use atomics rather than latches |