Dean Rasheed <dean.a.rash...@gmail.com> writes:
> On 1 August 2011 18:55, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Aug 1, 2011 at 1:42 PM, Dean Rasheed <dean.a.rash...@gmail.com> wrote:
>>> Don't we already do that when pruning HOT chains?
>> I thought that only happens after the transaction is committed, and
>> old enough, whereas the trigger code only needs to follow the chain in
>> the updating transaction.
> Hmm, true.
On reflection I think we're probably worrying over nothing. The only
way that the t_ctid link might have gotten changed (given that the
original updating subtransaction hasn't been aborted) is if we were
willing to prune an inserted-and-then-deleted-in-same-xact tuple out of
the t_ctid link chain while its parent xact is still running. However,
it is unsafe to do that unless you know for certain that the xact in
question has no snapshots that could see the tuple as live. VACUUM
certainly doesn't know that, and neither does pruneheap.c, and I don't
really foresee us introducing enough bookkeeping so that they would know
it. (If we did try to do that, we could handle the problem by
considering that queueing of trigger events introduces a quasi-snapshot
that requires the relevant tuples to remain available.)
So I think this is probably OK as long as it's adequately documented in
the code. Just for luck, though, we should add an xmin/cmin match check
to the code if there's not one already.
However, this means that Dean is not simply adding some self-contained
compression logic; he's eliminating information from the data structure
on the grounds that he can get it from elsewhere. I think that that
ought to be treated as a separate patch, and that the costs/benefits
of the "compressed" data structure ought to be evaluated relative to the
situation with the second CTID removed but the data structure not
otherwise changed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
