From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WAL dirty-buffer management bug |
Date: | 2006-03-31 15:10:13 |
Message-ID: | 8298.1143817813@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-03-31 15:35:31 | Re: Slony-I for circular replication |
Previous Message | Tom Lane | 2006-03-31 14:36:20 | Re: WAL dirty-buffer management bug |