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

On Mon, Mar 5, 2012 at 4:32 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

I agree behaviour is wrong, the only question is whether our users
rely in some way on that behaviour. Given the long discussion on that
point earlier I thought it best to add a GUC. Easy to remove, now or
later.

> 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.

err, very good point. Doh.

> 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.

OK, that makes sense and works if we need to rebuild relcache.

> 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.

Yeh that was designed-to-be-replaced text. We do use DDL already
elsewhere without really explaining it; its also one of those acronyms
that doesn't actually explain what it really means very well. So I
like the phrase you suggest.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services