On Thu, Oct 16, 2025 at 12:00 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Oct 15, 2025 at 10:27 AM Srinath Reddy Sadipiralla
> > ,the main problem is when if someone manually places an invalid WAL file
> > in pg_wal like 00000001FFFFFFFFFFFFFF10, IsXLogFileName will
> > consider it as valid ,so with the approach as i mentioned earlier we can
> > catch such cases.
>
> I think that parsing the file name may be a good idea so that we can
> do appropriate sanity checks on the values (e.g. checking that we're
> only skipping copying prior to last_common_segno), but I do not think
> we should worry too much about the user manually injecting invalid WAL
> files. I mean, I would prefer that if that does happen, it either
> works anyway or fails with a sensible error message, rather than
> emitting an incomprehensible error message or dumping core. But, it is
> in general true that if manual modifications are made to the data
> directory, things may go terribly wrong, and this code is not obliged
> to provide any more protection against such scenarios than we do in
> other cases. Ultimately, such modifications are user error.
>
It feels like there's a lot of things we could attempt to ensure
"correctness" if we are concerned about scenarios when the user manually puts
or modifies content unexpectedly in the pg_wal directory.
For instance, one could make the argument that when considering to skip
copying the common WAL segments, even though they are of the same
size, it's possible the user has manipulated them directly. I don't
think we need to
run checksums on every WAL segment that is a valid candidate to ensure they
match.
--
John Hsu - Amazon Web Services
