Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"

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: Raw Message | Whole Thread | 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

In response to

Responses

Browse pgsql-bugs by date

  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"