Re: uninterruptable loop: concurrent delete in progress within table

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
>> Have we really pinned down the semantics of the the return values
>> for HeapTupleSatisfiesVacuum() at this point?
>
> Well, now that Andres unilaterally redefined HEAPTUPLE_INSERT_IN_PROGRESS
> as meaning whatever the heck was easiest, I'd say no ;-).

That's kinda what I was afraid of.

> But we have to
> think about what we do want from it.  I'm not sure that we can positively
> guarantee to distinguish all the possible states of an update-in-progress
> tuple from outside the updating backend, and it likely would not be worth
> the trouble to try since the answer could change at any instant anyway.

That sounds like way more than SSI needs anyway.

> For the statistical purposes I was on about in the other thread, I would
> be satisfied if we could distinguish "will be live if all relevant
> transactions commit" from "will be dead if all relevant transactions
> commit".

If I'm understanding you, and if HEAPTUPLE_LIVE and HEAPTUPLE_DEAD
are clear-cut "nothing is in progress" cases, I think that might be
enough.  We know coming in whether the tuple is visible to our own
transaction; the question is whether its existence has been or is
potentially being changed by a top level transaction whose work we
can't see.  Ideally we would ignore the effects of a subtransaction
underneath such a top level transaction if that subtransaction has
rolled back, but it would only compromise efficiency (not
correctness) if we didn't ignore the work of subtransactions which
have already been rolled back on an uncommitted top-level transaction.

>> What the code in predicate.c is using this for is to determine, for
>> a given tuple which the calling process is reading, whether it is
>> visible to the calling process but has been deleted by another
>> transaction (whose work this snapshot can't see), or is not visible
>> to the calling process and has been inserted by another transaction
>> (whose work this transaction can't see).
>
> I'm not sure why you'd need HeapTupleSatisfiesVacuum for that at all
> --- it sounds like a plain visible-according-to-query-snapshot test.

That is *one* of the things we need, and it is passed in as a bool
parameter.  We also need to know whether another transaction has
committed, or might commit, something which would delete a visible
tuple or insert a tuple which is not visible to us (but which has
been read on a scan).  In other words, would the results of this
scan be different if run again after commit of the other
transaction?  We're talking about the
CheckForSerializableConflictOut() function, in case my description
here isn't clear; perhaps the function comments and/or code will
clarify things.

http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/storage/lmgr/predicate.c;h=7c8d53e6a5a44e8bbbda453c730bb5073f8a3842;hb=master#l3850

> Certainly HTSV is unconcerned with visibility as such, so it can't
> satisfy this requirement by itself.

Right.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company