| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Subject: | Re: More race conditions in logical replication |
| Date: | 2017-07-07 22:52:30 |
| Message-ID: | 20170707225230.oucbqrx4myqbrtqy@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-07-07 23:01:25 | Re: More race conditions in logical replication |
| Previous Message | Peter Geoghegan | 2017-07-07 20:30:48 | Re: [WIP] Zipfian distribution in pgbench |