pg_rewind: Skip vanished source files during traversal

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_rewind: Skip vanished source files during traversal
Date: 2026-05-28 06:01:16
Message-ID: CAJTYsWVoJ7-TdjGw3jQ40+a7cBYjr2GZLEC_tyE22ZKqQnDrWQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While looking at pg_rewind's source directory traversal, I noticed a small
thing in recurse_dir() that I wanted to ask about.

When lstat() fails with ENOENT, the existing comment says that this is OK
when scanning a live source data directory, because the file may have been
removed by the new primary:

File doesn't exist anymore. This is ok, if the new primary
is running and the file was just removed.

But after that branch, the code continues and later checks fst.st_mode to
decide whether the entry is a regular file, directory, or symlink. Since
lstat() failed in that case, is fst still safe to inspect? It seems to me
that the intended behavior might be to skip that directory entry once ENOENT
is accepted.

The attached patch adds a continue in that branch.

I tested this with a small harness around traverse_datadir() and an lstat()
shim that returns ENOENT for one directory entry. Without the patch, the
callback was still invoked for that entry; with the patch, it was skipped.

Does this interpretation make sense, or is there a reason we should continue
processing the entry after ENOENT?

Regards,
Ayush

Attachment Content-Type Size
v1-0001-pg_rewind-Skip-vanished-source-files-while-sca.patch application/octet-stream 1.2 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2026-05-28 07:25:00 new connection establishment (pgbench --connect) slow with pgbouncer due to libpq/OpenSSL global thread contention
Previous Message Chao Li 2026-05-28 05:46:45 Re: Set notice receiver before libpq connection startup