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

From Simon Riggs
Subject Re: RFC: Making TRUNCATE more "MVCC-safe"
Date
Msg-id CA+U5nM+ypvDX7-RbGLmDkGXhkAg9AFGPjg_6jgYSnRX+Ukd7DQ@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Making TRUNCATE more "MVCC-safe"  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Mon, Mar 5, 2012 at 5:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> Well, there's no point that I can see in having two checks.  I just
> dislike the idea that we have to remember to add this check for every
> method of accessing the relation - doesn't seem terribly future-proof.
>  It gets even worse if you start adding checks to DDL code paths - if
> we're going to do that, we really need to cover them all, and that
> doesn't seem very practical if they're going to spread out all over
> the place.

Understood. Will look.

> I don't understand your comment that a snapshot doesn't get associated
> with a relation until scan time.  I believe we associated a snapshot
> with each query before we even know what relations are involved; that
> query then gets passed down to all the individual scans.  The query
> also opens and locks those relations.  We ought to be able to arrange
> for the query snapshot to be cross-checked at that point, rather than
> waiting until scan-start time.

What's to stop other code using an older snapshot explicitly? That
fear may be bogus.

Any suggestions? ISTM we don't know whether we're already locked until
we get to LockAcquire() and there's no easy way to pass down snapshot
information through that, let alone handle RI snapshots. Ideas please.

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


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Our regex vs. POSIX on "longest match"
Next
From: Pavel Stehule
Date:
Subject: Re: elegant and effective way for running jobs inside a database