| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> | 
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> | 
| Cc: | pgsql-bugs(at)postgresql(dot)org | 
| Subject: | Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2" | 
| Date: | 2013-03-27 19:04:47 | 
| Message-ID: | 515342CF.1080805@vmware.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
On 27.03.2013 20:27, Josh Berkus wrote:
> Folks,
>
> So I'm a bit surprised that this bug report hasn't gotten a follow-up.
> Does this sound like the known 9.2.2 corruption issue, or is it
> potentially something else?
It seems like a new issue. At a quick glance, I think there's a bug in 
heap_xlog_update, ie. the redo routine of a heap update. If the new 
tuple is put on a different page, and at redo, the new page doesn't 
exist (that's normal if it was later vacuumed away), heap_xlog_update 
leaks a pin on the old page. Here:
> 	{
> 		nbuffer = XLogReadBuffer(xlrec->target.node,
> 								 ItemPointerGetBlockNumber(&(xlrec->newtid)),
> 								 false);
> 		if (!BufferIsValid(nbuffer))
> 			return;
> 		page = (Page) BufferGetPage(nbuffer);
>
> 		if (XLByteLE(lsn, PageGetLSN(page)))	/* changes are applied */
> 		{
> 			UnlockReleaseBuffer(nbuffer);
> 			if (BufferIsValid(obuffer))
> 				UnlockReleaseBuffer(obuffer);
> 			return;
> 		}
> 	}
Notice how in the first 'return' above, obuffer is not released.
I'll try to create a reproducible test case for this, and fix..
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-03-27 19:48:33 | Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2" | 
| Previous Message | Josh Berkus | 2013-03-27 18:27:33 | Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2" |