Re: More race conditions in logical replication
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2017-07-12T22:48:28Z
Lists: pgsql-hackers
Attachments
Petr Jelinek wrote: > So best idea I could come up with is to make use of the new condition > variable API. That lets us wait for variable which can be set per slot. Here's a cleaned up version of that patch, which I intend to get in the tree tomorrow. I verified that this allows the subscription tests to pass with Tom's sleep additions. I noticed one point where we're reading the active_pid without locking; marked it with an XXX comment. Not yet sure whether this is a bug or not. I noticed something funny in CREATE_REPLICATION; apparently we first create a slot and set it active, then we activate it by name. With the current coding it seems to work fine, because we're careful to make activation idempotent, but it looks convoluted. I don't think this is new, though. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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