| 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 |
| 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 |