Luca Ferrari wrote:
> Thanks all for your comments. Just another little hint here (sorry for trivial
> questions):
>
> if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple)))
> {
> if (tuple->t_infomask & HEAP_IS_LOCKED)
> return true;
> if (HeapTupleHeaderGetCmax(tuple) >= GetCurrentCommandId())
> return true; /* deleted after scan started */
> else
> return false; /* deleted before scan started */
> }
>
> what does that "deleted after scan started" means? How is possible that the
> current transaction has deleted the tuple with a command higher than the one
> that is still executing?
It is possible.
> An example could clearify....
Consider an open cursor; you open it and leave it there. Then you
delete something from the table. Then you read from the cursor. The
deleted row must be in the cursor.
FK triggers have somewhat "interesting" behavior here as well. I'm not
sure if it's an issue in this particular case but they do tend to push
the limits of this stuff.
BTW "clarify" is one of these weird things about english during which
you make something "clear" instead of "clar". So you don't "clearify"
things. It just doesn't make any sense -- that's why it's english.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
