Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
От | Simon Riggs |
---|---|
Тема | Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly |
Дата | |
Msg-id | CANP8+j+L+pOBeSu7JeNSn1fGz7SO4p1mewKhqN7d4Xv9+7+EKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
|
Список | pgsql-hackers |
On 23 April 2017 at 17:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndquadrant.com> writes: >>> Also, when I fix that, it gets further but still crashes at the same >>> Assert in SubTransSetParent. The proximate cause this time seems to be >>> that RecoverPreparedTransactions's calculation of overwriteOK is wrong: >>> it's computing that as "false", but in reality the subtrans link in >>> question has already been set. > >> Not sure about that, investigating. > > As a quick hack, I just hotwired RecoverPreparedTransactions to set > overwriteOK = true always, and with that and the SubTransSetParent > argument-order fix, HEAD passes the recovery tests. Maybe we can > be smarter than that, but this might be a good short-term fix to get > the buildfarm green again. That would work. I've been looking into a fix I can explain, but "do it always" may actually be it. OK, I'll do that. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: