Re: pg_rewind: Skip vanished source files during traversal

Hi.

On Mon, 6 Jul 2026 at 18:49, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 28/05/2026 09:01, Ayush Tiwari wrote:
> >
> > Does this interpretation make sense, or is there a reason we should
> continue
> > processing the entry after ENOENT?
>
> So, the full comment is:
>
> > /*
> > * File doesn't exist anymore. This is ok, if the new primary
> > * is running and the file was just removed. If it was a data
> > * file, there should be a WAL record of the removal. If it
> > * was something else, it couldn't have been anyway.
> > *
> > * TODO: But complain if we're processing the target dir!
>
> That explanation doesn't make a whole lot of sense to me. We don't
> support running pg_rewind on a source directory while the source server
> is running. We do support the "connection" mode on a running server, but
> that doesn't use this function. (And it's not clear what the "couldn't
> have been anyway" means here. Mea culpa, I wrote that comment)

> And it would indeed be nice to implement that TODO. But AFAICS we should
> just always throw an error here. It's not OK if a file goes missing in
> the target dir, and we don't expect it in the source dir either, because
> the server shouldn't be running.
>

Ahh, yes you are right. I'd only been looking at the uninitialized
fst.st_mode read (lstat() fails, but the code still inspects st_mode),
and continue was the minimal way to avoid it.

In supported paths, recurse_dir() only runs on a stopped local source
data directory or the target data directory; the running-source case
goes through libpq_traverse_files(). So a vanished file isn't expected
there, and erroring would be the better fix.

v2 attached: it just pg_fatal()s on lstat() failure, dropping the ENOENT
special case and the TODO.

Regards,
Ayush