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-07T22:52:30Z
Lists: pgsql-hackers
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. > > It's not backportable however, I am not sure how big problem that is > considering the lack of complaints until now (maybe we could backport > using the ugly timeout version?). > > The attached patch is a prototype of such solution and there are some > race conditions (variable can get signaled before the waiting process > starts sleeping for it). I am mainly sending it to get feedback on the > approach. This one looks a lot better than the original one. I wonder if it's possible to do this using lwlocks instead of condition variables (similar to how we do the "wait for IO" thing both for slots and buffers). We could backport that easily ... I'll next update this on or before Monday 10th at 19:00 CLT. -- Á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