Re: [HACKERS] PANIC in pg_commit_ts slru after crashes
От | Simon Riggs |
---|---|
Тема | Re: [HACKERS] PANIC in pg_commit_ts slru after crashes |
Дата | |
Msg-id | CANP8+j+Era0AS57QPqL-7pD0mvsg0CoEzPsDvUGSqdCQ49JJjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] PANIC in pg_commit_ts slru after crashes (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] PANIC in pg_commit_ts slru after crashes
|
Список | pgsql-hackers |
On 18 April 2017 at 09:51, Simon Riggs <simon@2ndquadrant.com> wrote: > On 17 April 2017 at 16:33, Jeff Janes <jeff.janes@gmail.com> wrote: >> On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier <michael.paquier@gmail.com> >> wrote: >>> >>> >>> >>> Jeff, does this patch make the situation better? The fix is rather >>> simple as it just makes sure that the next XID never gets updated if >>> there are no 2PC files. >> >> >> Yes, that fixes the reported case when 2PC are not being used. > > Thanks Jeff. > > I certainly prefer the simplicity of Michael's approach. I'll move to commit. Minor change to patch. I've added a recheck in ProcessTwoPhaseBuffer() after we acquire the lock. If its worth acquiring the lock its worth checking we don't have a race. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: