Re: Making pg_rewind faster

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: John H <johnhyvr(at)gmail(dot)com>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Justin Kwan <justinpkwan(at)outlook(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh ravichandran <admin(at)viggy28(dot)dev>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>
Subject: Re: Making pg_rewind faster
Date: 2025-10-23 12:40:14
Message-ID: CA+TgmoaycvKEkh8Vpf-ZS-PrHUT8dSx=53qUUiMKgLq4CicdcQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 23, 2025 at 4:22 AM Michael Paquier <michael(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2025-10-23 12:58:46 Re: Implement waiting for wal lsn replay: reloaded
Previous Message Sergey Prokhorenko 2025-10-23 12:34:43 Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions