Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
От | Yunong Xiao |
---|---|
Тема | Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2" |
Дата | |
Msg-id | A7208DDC-7306-4A2F-82B8-669582AE8DF3@joyent.com обсуждение исходный текст |
Ответ на | Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2" (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Apr 11, 2013, at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Yunong Xiao" <yunong@joyent.com> writes: >> On Mar 27, 2013, at 12:48 PM, Heikki Linnakangas <hlinnakangas@vmware.co= m> wrote: >>> This bug was introduced by commit 8805ff6580621d0daee350826de5211d6bb36= ec3, in 9.2.2 (and 9.1.7 and 9.0.11), which fixed multiple WAL replay issue= s 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 co= rrectness of hot standby. The patch fixed that, but missed releasing the ol= d buffer in this corner case. I was not able to come up with a scenario wit= h full_page_writes=3Don where this would fail, but I'm also not 100% sure i= t can't happen. >>>=20 >>> I scanned through the commit, and couldn't see any other instances of t= his kind of a bug. heap_xlog_update is more complicated than other redo fun= ctions, with all the return statements inside it. It could use some refacto= ring, but for now, I'll commit the attached small fix. >>>=20 >>> - Heikki >>> <fix-heap-update-redo-buffer-leak.patch> >=20 >> Heikki: >=20 >> Is it safe to apply the patch you attached? We'd really like to roll out= this fix to production instead of waiting for this to be released as a pos= tgres minor version update. >=20 > Eh? That patch *is* in the latest minor versions. >=20 > regards, tom lane Indeed it is. My apologies. Thanks so much for the fix!=
В списке pgsql-bugs по дате отправления: