On 2014-06-02 14:39:22 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
> > It essentially is. If xmax aborts you still have to deal with an
> > 'INSERT_IN_PROGRESS' tuple because, as you say, xmin is still
> > running. That's essentially my point. INSERT_IN_PROGRESS isn't a wrong
> > answer.
>
> Uh. Actually it strikes me that DELETE_IN_PROGRESS is a wrong answer in
> the XidIsInProgress(xmin) block anyhow. If the tuple is being inserted
> remotely, there is no way we can return DELETE_IN_PROGRESS, is there?
I don't think it'd break stuff if we did it in the !IsCurrent()
case. But yes, that's why I made the TransactionIdIsInProgress(xmin)
block unconditionally return INSERT_IN_PROGRESS.
> Another thing I wanted to comment on originally is that I'm not sure
> about the CHECK_FOR_INTERRUPTS() additions. Aren't those only to serve
> the case of the current bug, or bugs of similar ilk? There is no way
> that a valid, non-bug situation is going to cause us to loop forever
> there.
I think there's other possible cases where it loop for a long
while. Think e.g. of a row that's updated under contention by several
backends or such.
> That said, there isn't much harm in having them there either,
> but I think I'd put them before the xact wait, not after.
XactLockTableWait() internally catches waits if they happen while
waiting, so that's covered. I am mainly concerned with xmax changing
frequently...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services