From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Date: | 2012-12-09 18:44:27 |
Message-ID: | 20121209184427.GA21520@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 05, 2012 at 07:43:08PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Dec 4, 2012 at 3:38 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> >> After reading that thread, I still don't understand why it's unsafe to
> >> set HEAP_XMIN_COMMITTED in those conditions. Even if it is, I would
> >> think that a sufficiently narrow case -- such as CTAS outside of a
> >> transaction block -- would be safe, along with some slightly broader
> >> cases (like BEGIN; CREATE TABLE; INSERT/COPY).
>
> > I haven't looked at the committed patch - which seemed a bit
> > precipitous to me given the stage the discussion was at - but I
> > believe the general issue with HEAP_XMIN_COMMITTED is that there might
> > be other snapshots in the same transaction, for example from open
> > cursors.
>
> From memory, the tqual.c code assumes that any tuple with XMIN_COMMITTED
> couldn't possibly be from its own transaction, and thus it doesn't make
> the tests that would be appropriate for a tuple that is from the current
> transaction. Maybe it's all right anyway (i.e. if we should always treat
> such a tuple as good) but I don't recall exactly what's tested in those
> paths.
I don't see semantics preservable by freezing, yet omitting
HEAP_XMIN_COMMITTED. The "HeapTupleHeaderGetCmin(tuple) >= snapshot->curcid"
test is the one at risk. HeapTupleSatisfiesMVCC() does skip that test for
HEAP_XMIN_COMMITTED tuples, but seeing xmin==FrozenTransactionId hampers it
all the more.
What if one of the preconditions for the optimization were the equivalent of
CheckTableNotInUse()? I cannot immediately think of a older-cmin-scan source
not caught thereby. Unmodified HeapTupleSatisfiesMVCC() will then suffice.
Happily, it's not a restriction users will regularly encounter.
Thanks,
nm
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2012-12-09 18:47:06 | Re: CommitFest #3 and upcoming schedule |
Previous Message | Tomas Vondra | 2012-12-09 18:06:39 | Re: New statistics for WAL buffer dirty writes |