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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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 17:42:20
Message-ID: CA+U5nM+=Wopi9nU=QLcTjEyY4s7qWdJcb+1pZBSOn_amWuOUBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 5, 2012 at 4:46 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

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

Except the reason to do it at the start of the scan is that is the
first time a specific snapshot has been associated with a relation and
also the last point we can apply the check before the errant behaviour
occurs.

If we reject locks against tables that might be used against an
illegal snapshot then we could easily prevent valid snapshot use cases
when a transaction has multiple snapshots, one illegal, one not.

We can certainly have a looser test when we first get the lock and
then another test later, but I don't think we can avoid making all
scans apply this test. And while I'm there, we have to add tests for
things like index build scans.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-05 17:43:53 Re: RFC: Making TRUNCATE more "MVCC-safe"
Previous Message Robert Haas 2012-03-05 17:28:24 Re: Our regex vs. POSIX on "longest match"