Re: assertion failure 9.3.4
От | Josh Berkus |
---|---|
Тема | Re: assertion failure 9.3.4 |
Дата | |
Msg-id | 5356E1DE.9010002@agliodbs.com обсуждение исходный текст |
Ответ на | assertion failure 9.3.4 (Andrew Dunstan <andrew.dunstan@pgexperts.com>) |
Ответы |
Re: assertion failure 9.3.4
|
Список | pgsql-hackers |
On 04/22/2014 02:01 PM, Alvaro Herrera wrote: > Some testing later, I think the issue only occurs if we determine that > we don't need to wait for the xid/multi to complete, because otherwise > the wait itself saves us. (It's easy to cause the problem by adding a > breakpoint in heapam.c:3325, i.e. just before re-acquiring the buffer > lock, and then having transaction A lock for key share, then transaction > B update the tuple which stops at the breakpoint, then transaction A > also update the tuple, and finally release transaction B). So, trying to make my synthetic test work: In order to encounter this issue, I'd need to have two concurrent processes update the child records of the same parent record? That is: A ---> B1 \---> B2 ... and the issue should only happen if I update both B1 and B2 concurrently in separate sessions? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: