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 20:10:46
Message-ID: CA+U5nM+ypvDX7-RbGLmDkGXhkAg9AFGPjg_6jgYSnRX+Ukd7DQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-03-05 20:17:40 Re: elegant and effective way for running jobs inside a database
Previous Message Martijn van Oosterhout 2012-03-05 20:06:11 Re: Our regex vs. POSIX on "longest match"