Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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)

pgsql-committers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group