Re: Making pg_rewind faster - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Making pg_rewind faster
Date
Msg-id CA+TgmoaycvKEkh8Vpf-ZS-PrHUT8dSx=53qUUiMKgLq4CicdcQ@mail.gmail.com
Whole thread Raw
In response to Re: Making pg_rewind faster  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Oct 23, 2025 at 4:22 AM Michael Paquier <michael@paquier.xyz> wrote:
> +    * However we check last_common_segno and file_size again for sanity.
> +    */
> +   if (file_segno < last_common_segno && source_size == target_size)
>
> What if a segment has a size different than the one a cluster has been
> initialized with, still both have the same size on the target and the
> source?  Unlikely, still incorrect if not cross-checked with what a
> control file has in store.  :)

While I'm not against cross-checking against the control file, this
sounds like an imaginary scenario to me. That is, it would only happen
if somebody maliciously modified the contents of the data directory by
hand with the express goal of breaking the tool. But we fundamentally
cannot defend against a malicious user whose express goal is to break
the tool, and I do not see any compelling reason to expend energy on
it even in cases like this where we could theoretically detect it
without much effort. If we go down that path, we'll end up not only
complicating the code, but also obscuring our own goals: it will look
like we've either done too much sanity checking (because we will have
added checks that are unnecessary with a non-malicious user) or too
little (because we will not have caught all the things a malicious
user might do).

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Sergey Prokhorenko
Date:
Subject: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions
Next
From: Xuneng Zhou
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded