Re: WAL dirty-buffer management bug

"Qingqing Zhou" <zhouqq@cs.toronto.edu> 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