Re: WAL dirty-buffer management bug

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)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