Reset unlogged relations before syncing the data directory?

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Reset unlogged relations before syncing the data directory?
Date: 2026-10-07 21:20:51
Message-ID: CAJTYsWW_tx5ZacHLjCLHyvPkcjc=y3OncLJJ4xyL7rwOFzGkkw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

During crash startup we sync the unlogged forks, only to remove them later.
ISTM we could avoid that writeback by doing the cleanup first.

The attached patch puts the cleanup after InitWalRecovery() has restored
any tablespace links, but before SyncDataDirectory(). Init forks and
surviving files are still synced before replay, and the end-of-recovery
checkpoint stays where it is.

I've kept the later cleanup for recovery after a clean shutdown. We need
pg_control to record recovery first, otherwise a failed start could leave
missing unlogged files without forcing recovery on the next normal start.

AFAICS this should help recovery_init_sync_method=syncfs too, since it
can't skip individual files.

I got the following startup times on a Linux VM (8 vCPUs, 32 GB RAM) with
ext4, using a 1.14 GiB unlogged table (four runs each):

Method Unpatched median (range) Patched median
fsync 26.34 s (21.83-27.34) 0.40 s
syncfs 22.58 s (19.43-23.93) 0.30 s

The empty-table fsync control had a 0.30 s median for both builds.

Does this ordering look reasonable, or am I missing a reason the initial
sync needs to happen before InitWalRecovery()?

Regards,
Ayush

P.S. These runs were right after a load and pg_ctl stop -m immediate,
without a manual cache flush, so there may still have been dirty data in
the OS page cache at restart (which could explain such big gains)

Attachment Content-Type Size
v1-0001-Reset-unlogged-relations-before-syncing-the-data-directory.patch application/octet-stream 4.0 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-10-07 21:44:35 Re: [PROPOSAL] Expand OR clauses in joins to UNION ALL paths
Previous Message Masahiko Sawada 2026-10-07 20:41:41 Re: Parallel vacuum: I/O timings in the log leave out the parallel workers