On Mon, 6 Jul 2026 at 18:49, Heikki Linnakangas <hlinnaka@iki.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.
