Re: More race conditions in logical replication
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2017-07-25T18:32:30Z
Lists: pgsql-hackers
On Tue, Jul 25, 2017 at 5:47 AM, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote: > As a side note, the ConditionVariablePrepareToSleep()'s comment could be > improved because currently it says the only advantage is that we skip > double-test in the beginning of ConditionVariableSleep(). But that's not > true, it's essential for preventing race conditions like the one above > because it puts the current process into waiting list so we can be sure > it will be signaled on broadcast once ConditionVariablePrepareToSleep() > has been called. But if you don't call ConditionVariablePrepareToSleep() before calling ConditionVariableSleep(), then the first call to the latter will call the former and return without doing anything else. So I don't see how this can ever go wrong if you're using these primitives as documented. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Fix vertical spanning in table "wait_event Description".
- e88928c50dfe 10.0 landed
-
Fix replication origin-related race conditions
- b2c95a3798ff 10.0 landed
-
Fix inadequacies in recently added wait events
- 030273b7ea46 10.0 landed
-
Fix race conditions in replication slot operations
- 9915de6c1cb2 10.0 landed