Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2" - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
Date
Msg-id 515342CF.1080805@vmware.com
Whole thread Raw
In response to Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
List 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

pgsql-bugs by date:

Previous
From: Josh Berkus
Date:
Subject: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
Next
From: Heikki Linnakangas
Date:
Subject: Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"