| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: LWLock deadlock and gdb advice |
| Date: | 2015-06-30 20:24:43 |
| Message-ID: | 20150630202443.GL20882@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-06-30 22:19:02 +0300, Heikki Linnakangas wrote:
> >Hm. Right. A recheck of the value after the queuing should be sufficient
> >to fix? That's how we deal with the exact same scenarios for the normal
> >lock state, so that shouldn't be very hard to add.
>
> Yeah. It's probably more efficient to not release the spinlock between
> checking the value and LWLockQueueSelf() though.
Right now LWLockQueueSelf() takes spinlocks etc itself, and is used that
way in a bunch of callsites... So that'd be harder. Additionally I'm
planning to get rid of the spinlocks around queuing (they show up as
bottlenecks in contended workloads), so it seems more future proof not
to assume that either way. On top of that I think we should, when
available (or using the same type of fallback as for 32bit?), use 64 bit
atomics for the var anyway.
> I'll take a stab at fixing this tomorrow.
Thanks! Do you mean both or "just" the second issue?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2015-06-30 20:28:38 | Re: pg_trgm version 1.2 |
| Previous Message | Heikki Linnakangas | 2015-06-30 19:19:02 | Re: LWLock deadlock and gdb advice |