Re: pg_rewind does not rewind diverging timelines

From: Mats Kindahl <mats(dot)kindahl(at)gmail(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_rewind does not rewind diverging timelines
Date: 2026-07-26 05:11:06
Message-ID: 8683af69-28af-4a2d-a1db-aa1447b02446@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Zsolt,

Thank you for reviewing this and sorry for the delay. I have attached a
new version with the issues you pointed to handled. See comments inline
below.

Best wishes,
Mats Kindahl

On 6/8/26 21:52, Zsolt Parragi wrote:

> Hello
>
> I know there's still ongoing discussion on the direction itself, but I
> focused on just testing and looking at the latest patch, in case the
> fix remains the same.
>
> + PG_CATCH();
> + {
> + ErrorData *edata = CopyErrorData();
> +
> + FlushErrorState();
> + ereport(FATAL,
> + errmsg("invalid UUID in history file \"%s\"", path),
> + errdetail("%s", edata->message));
> + }
>
> This is missing a MemoryContextSwitchTo before CopyErrorData, and
> results in an assertion with debug builds.
>
> + memset(&entry->tluuid, 0, sizeof(pg_uuid_t));
> + if (nfields == 4 && strlen(uuid_str) == UUID_STR_LEN)
> + rewind_parse_uuid(uuid_str, &entry->tluuid);
>
> This ignores the return value of rewind_parse_uuid, possibly writing
> partial garbage to tluuid on incorrect input.
>
> Also, it seems like that with this patch, pg rewind requires the
> target's history file to be always there - is this an intended change?
> If yes, then it should be at least mentioned somewhere.
>
> On master:
> exit 0
> "source and target cluster are on the same timeline"
> "no rewind required"
>
> On patched rewind:
> exit 1
> error: could not open file
> ".../tgt/pg_wal/00000002.history" for reading: No such file or directory

That was not the intention, so I added a check for a target history file
to the code and a test that checks the behavior without a timeline
history file and compared that with the behavior before the change.

>
>
> writeTimeLineHistory(TimeLineID newTLI, TimeLineID parentTLI,
> + const pg_uuid_t *newTLUUID,
> XLogRecPtr switchpoint, char *reason)
>
> In case this is a bug that should be backported, wouldn't this be an ABI break?
>
>
> +#endif /* !FRONTEND */
> +
> +extern pg_uuid_t *generate_uuidv7(uint64 unix_ts_ms, uint32 sub_ms);
> +extern pg_uuid_t *generate_uuidv7_r(pg_uuid_t *uuid, uint64
> unix_ts_ms, uint32 sub_ms);
>
> Shouldn't these go before the endif?

I thought the generate_uuidv7 should be possible to use for a frontend,
but looking at how it is written and linked, that is not possible to I
moved the #endif.

Attachment Content-Type Size
v7.0001-pg_rewind-use-UUIDs-to-detect-independent-same-TLI-p.patch text/x-patch 43.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ChenhuiMo 2026-07-26 05:30:32 [PATCH] Speed up repeat() for larger counts
Previous Message Jacob Brazeal 2026-07-26 04:27:53 Re: remove_useless_joins vs. bug #19560