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

From: Noah Misch <noah(at)leadboat(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Making TRUNCATE more "MVCC-safe"
Date: 2012-03-06 09:54:59
Message-ID: 20120306095459.GA15988@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 04, 2012 at 01:02:57PM +0000, Simon Riggs wrote:
> More detailed thoughts show that the test in heap_beginscan_internal()
> is not right enough, i.e. wrong.
>
> We need a specific XidInMVCCSnapshot test on the relvalidxid, so it
> needs to be a specific xid, not an xmin because otherwise we can get
> concurrent transactions failing, not just older transactions.

Good point; I agree. indcheckxmin's level of pessimism isn't appropriate for
this new check.

> If we're going freeze tuples on load this needs to be watertight, so
> some minor rework needed.
>
> Of course, if we only have a valid xid on the class we might get new
> columns added when we do repeated SELECT * statements using the same
> snapshot while concurrent DDL occurs. That is impractical, so if we
> define this as applying to rows it can work; if we want it to apply to
> everything its getting more difficult.

Excess columns seem less grave to me than excess or missing rows. I'm having
difficulty thinking up an explanation for that opinion.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2012-03-06 10:09:08 Re: pgsql_fdw, FDW for PostgreSQL server
Previous Message Pavel Stehule 2012-03-06 09:33:54 Re: poll: CHECK TRIGGER?