Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtrans links incorrectly |
Дата | |
Msg-id | 2049.1493216926@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly (Nikhil Sontakke <nikhils@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] StandbyRecoverPreparedTransactions recovers subtranslinks incorrectly
|
Список | pgsql-hackers |
Nikhil Sontakke <nikhils@2ndquadrant.com> writes: > A SELECT query on the newly promoted master on any of the tables involved > in the 2PC hangs. The hang is due to a loop in > SubTransGetTopmostTransaction(). Due to incorrect linkages, we get a > circular reference in parentxid <-> subxid inducing the infinite loop. I'm inclined to propose that (1) SubTransSetParent should contain an assert that Assert(TransactionIdFollows(xid, parent)); There is a similar assertion near one of the call sites, but that's obviously too far away from the action. (2) SubTransGetTopmostTransaction ought to contain an actual runtime test and ereport (not just Assert) that the parent XID it got from pg_subtrans precedes the child XID that was looked up. This would protect us against similar infinite loops in the future. Even without bugs, such a loop could arise due to corrupted data. regards, tom lane
В списке pgsql-hackers по дате отправления: