Re: RFC: Making TRUNCATE more "MVCC-safe" - Mailing list pgsql-hackers

From Robert Haas
Subject Re: RFC: Making TRUNCATE more "MVCC-safe"
Date
Msg-id CA+TgmoY1V-NPiMiwK08ZqPjJnzeQ1uVRLnoFoFSPUsc0_sE-Kg@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Making TRUNCATE more "MVCC-safe"  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: RFC: Making TRUNCATE more "MVCC-safe"
List pgsql-hackers
On Sun, Mar 4, 2012 at 11:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Marti, please review this latest version which has new isolation tests added.
>
> This does both TRUNCATE and CREATE TABLE.

I don't see any need for a GUC to control this behavior.  The current
behavior is wrong, so if we're going to choose this path to fix it,
then we should just fix it, period.  The narrow set of circumstances
in which it might be beneficial to disable this behavior doesn't seem
to me to be sufficient to justify a behavior-changing GUC.

It does not seem right that the logic for detecting the serialization
error is in heap_beginscan_internal().  Surely this is just as much of
a problem for an index-scan or index-only-scan.  We don't want to
patch all those places individually, either: I think the check should
happen right around the time we initially lock the relation and build
its relcache entry.

The actual text of the error message could use some work.  Maybe
something like "could not serialize access due to concurrent DDL",
although I think we try to avoid using acronyms like DDL in
translatable strings.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Our regex vs. POSIX on "longest match"
Next
From: Heikki Linnakangas
Date:
Subject: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)