pgsql: Revise bgwriter fsync-request mechanism to improve robustness

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Revise bgwriter fsync-request mechanism to improve robustness
Date: 2007-01-17 00:17:21
Message-ID: 20070117001721.474A89FB1C0@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Log Message:
-----------
Revise bgwriter fsync-request mechanism to improve robustness when a table
is deleted. A backend about to unlink a file now sends a "revoke fsync"
request to the bgwriter to make it clean out pending fsync requests. There
is still a race condition where the bgwriter may try to fsync after the unlink
has happened, but we can resolve that by rechecking the fsync request queue
to see if a revoke request arrived meanwhile. This eliminates the former
kluge of "just assuming" that an ENOENT failure is okay, and lets us handle
the fact that on Windows it might be EACCES too without introducing any
questionable assumptions. After an idea of mine improved by Magnus.

The HEAD patch doesn't apply cleanly to 8.2, but I'll see about a back-port
later. In the meantime this could do with some testing on Windows; I've been
able to force it through the code path via ENOENT, but that doesn't prove that
it actually fixes the Windows problem ...

Modified Files:
--------------
pgsql/src/backend/postmaster:
bgwriter.c (r1.34 -> r1.35)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/bgwriter.c.diff?r1=1.34&r2=1.35)
pgsql/src/backend/storage/smgr:
md.c (r1.125 -> r1.126)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/md.c.diff?r1=1.125&r2=1.126)

Browse pgsql-committers by date

  From Date Subject
Next Message Bruce Momjian 2007-01-17 03:43:49 pgsql: Mark TODO item "autovacuum on by default" as completed.
Previous Message Neil Conway 2007-01-16 21:43:19 pgsql: vcbuild updates from Magnus: * After Markos patch, now builds