Re: RFC: Making TRUNCATE more "MVCC-safe"

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Making TRUNCATE more "MVCC-safe"
Date: 2012-03-05 16:32:48
Message-ID: CA+TgmoY1V-NPiMiwK08ZqPjJnzeQ1uVRLnoFoFSPUsc0_sE-Kg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 4, 2012 at 11:39 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2012-03-05 16:34:57 Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
Previous Message Tom Lane 2012-03-05 16:28:24 Re: Our regex vs. POSIX on "longest match"