"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> It may be not good but not harmful either. On step2, the transaction will
> abort and leave a page that has been changed but not marked dirty. There are
> two situtations could happen after that. One is step 3, the other is the
> page is still in the buffer pool and another transaction will write on it
> (no problem, the tuple slot is already marked used). For step 3, yes, we
> will see two WAL records trying to insert to the same tuple slot, but the
> 2nd one will cover the 1st one -- no problem.
Well, no, see the code in PageAddItem:
if (ItemIdIsUsed(itemId) || ItemIdGetLength(itemId) != 0)
{
elog(WARNING, "will not overwrite a used ItemId");
return InvalidOffsetNumber;
}
So during WAL replay the second insert will fail, leading to
elog(PANIC, "heap_insert_redo: failed to add tuple");
Removing that error check in PageAddItem doesn't strike me as a good
idea, either ;-)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
