On Tue, Jun 01, 2004 at 06:40:07PM -0400, Bruce Momjian wrote:
> When "DELETE a" happens, we remove the xmin=1 from the tuple header and
> replace it with xmin=3. xid=3 will be marked as committed if xid2
> aborts, and will be marked as aborted if xid3 commits.
>
> So, if xid2 aborts, the insert of xid1 should be honored, and xid3 is
> marked as committed, and the opposite if xid2 commits.
Ok, I've been looking at implementing this. However it just occurred to
me that a transaction, different from the one modifying the tuple, could
try to see its xmax.
Since the xmin signals the tuple as being updated concurrently by
another transaction (it's in progress), this can only happen if the
other transaction tries to read it using SnapshotDirty.
One such possible caller is EvalPlanQual. It could go to sleep using
XactLockTableWait() on the SnapshotDirty's xmax. But the tuple has
something strange in its xmax -- it's the tuple's cmin actually.
Leaving this would be probably a bug.
However, if the tuple is new, then EvalPlanQual won't even try to see
it. Or maybe it will. And then, maybe there are other callers (I can
only see _bt_check_unique).
Do I have to worry about this? Maybe (probably) it's not a problem, but
I want to be sure.
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El sentido de las cosas no viene de las cosas, sino de
las inteligencias que las aplican a sus problemas diarios
en busca del progreso." (Ernesto Hernández-Novich)