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

From Yunong Xiao
Subject Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
Date
Msg-id 21949434-BC5C-40B4-9A17-8AA4D665048F@gmail.com
Whole thread Raw
In response to Re: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mar 27, 2013, at 12:48 PM, Heikki Linnakangas <hlinnakangas@vmware.com> =
wrote:
>=20
> This bug was introduced by commit 8805ff6580621d0daee350826de5211d6bb36ec=
3, in 9.2.2 (and 9.1.7 and 9.0.11), which fixed multiple WAL replay issues =
with Hot Standby. Before that commit, replaying a heap update didn't try to=
 keep both buffers locked at the same time, which is necessary for the corr=
ectness of hot standby. The patch fixed that, but missed releasing the old =
buffer in this corner case. I was not able to come up with a scenario with =
full_page_writes=3Don where this would fail, but I'm also not 100% sure it =
can't happen.
>=20
> I scanned through the commit, and couldn't see any other instances of thi=
s kind of a bug. heap_xlog_update is more complicated than other redo funct=
ions, with all the return statements inside it. It could use some refactori=
ng, but for now, I'll commit the attached small fix.
>=20
> - Heikki
> <fix-heap-update-redo-buffer-leak.patch>

Heikki:

Is it safe to apply the patch you attached? We'd really like to roll out th=
is fix to production instead of waiting for this to be released as a postgr=
es minor version update.

-Yunong=

pgsql-bugs by date:

Previous
From: John R Pierce
Date:
Subject: Re: BUG #8056: postgres forgets hstore over time
Next
From: Tom Lane
Date:
Subject: Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"