pgsql: Fix up rickety handling of relation-truncation interlocks. - Mailing list pgsql-committers

From tgl@postgresql.org (Tom Lane)
Subject pgsql: Fix up rickety handling of relation-truncation interlocks.
Date
Msg-id 20100209214330.C1E297541B9@cvs.postgresql.org
Whole thread Raw
List pgsql-committers
Log Message:
-----------
Fix up rickety handling of relation-truncation interlocks.

Move rd_targblock, rd_fsm_nblocks, and rd_vm_nblocks from relcache to the smgr
relation entries, so that they will get reset to InvalidBlockNumber whenever
an smgr-level flush happens.  Because we now send smgr invalidation messages
immediately (not at end of transaction) when a relation truncation occurs,
this ensures that other backends will reset their values before they next
access the relation.  We no longer need the unreliable assumption that a
VACUUM that's doing a truncation will hold its AccessExclusive lock until
commit --- in fact, we can intentionally release that lock as soon as we've
completed the truncation.  This patch therefore reverts (most of) Alvaro's
patch of 2009-11-10, as well as my marginal hacking on it yesterday.  We can
also get rid of assorted no-longer-needed relcache flushes, which are far more
expensive than an smgr flush because they kill a lot more state.

In passing this patch fixes smgr_redo's failure to perform visibility-map
truncation, and cleans up some rather dubious assumptions in freespace.c and
visibilitymap.c about when rd_fsm_nblocks and rd_vm_nblocks can be out of
date.

Modified Files:
--------------
    pgsql/src/backend/access/heap:
        hio.c (r1.77 -> r1.78)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/hio.c?r1=1.77&r2=1.78)
        visibilitymap.c (r1.7 -> r1.8)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/visibilitymap.c?r1=1.7&r2=1.8)
    pgsql/src/backend/access/transam:
        xlogutils.c (r1.69 -> r1.70)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlogutils.c?r1=1.69&r2=1.70)
    pgsql/src/backend/catalog:
        storage.c (r1.9 -> r1.10)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/catalog/storage.c?r1=1.9&r2=1.10)
    pgsql/src/backend/commands:
        cluster.c (r1.199 -> r1.200)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/cluster.c?r1=1.199&r2=1.200)
        sequence.c (r1.164 -> r1.165)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/sequence.c?r1=1.164&r2=1.165)
        vacuum.c (r1.406 -> r1.407)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuum.c?r1=1.406&r2=1.407)
        vacuumlazy.c (r1.130 -> r1.131)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuumlazy.c?r1=1.130&r2=1.131)
    pgsql/src/backend/executor:
        execMain.c (r1.345 -> r1.346)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c?r1=1.345&r2=1.346)
    pgsql/src/backend/storage/freespace:
        freespace.c (r1.75 -> r1.76)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/freespace/freespace.c?r1=1.75&r2=1.76)
    pgsql/src/backend/storage/smgr:
        smgr.c (r1.119 -> r1.120)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/smgr.c?r1=1.119&r2=1.120)
    pgsql/src/backend/utils/cache:
        relcache.c (r1.304 -> r1.305)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c?r1=1.304&r2=1.305)
    pgsql/src/include/commands:
        vacuum.h (r1.88 -> r1.89)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/commands/vacuum.h?r1=1.88&r2=1.89)
    pgsql/src/include/storage:
        smgr.h (r1.69 -> r1.70)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/smgr.h?r1=1.69&r2=1.70)
    pgsql/src/include/utils:
        rel.h (r1.122 -> r1.123)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/rel.h?r1=1.122&r2=1.123)

pgsql-committers by date:

Previous
From: heikki@postgresql.org (Heikki Linnakangas)
Date:
Subject: pgsql: Fix bug in GIN WAL redo cleanup function: don't free fake
Next
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql: Improve planner's choices about when to use hashing vs sorting