| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Subject: | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |
| Date: | 2014-02-10 16:41:10 |
| Message-ID: | 20140210164110.GC15246@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-02-10 11:20:30 -0500, Tom Lane wrote:
> I wrote:
> > You didn't really explain why you think that ordering is necessary?
>
> Actually, after grepping to check my memory of what those fields are
> being used for, I have a bigger question: WTF is xlog.c doing being
> so friendly with the innards of LWLocks? Surely this needs to get
> refactored so that most of WakeupWaiters() and friends is in lwlock.c.
> Or has all notion of modularity gone out the window while I wasn't
> looking?
Well, it's not actually using any lwlock.c code, it's a special case
locking logic, just reusing the datastructures. That said, I am not
particularly happy about the amount of code it's duplicating from
lwlock.c. Pretty much all of WALInsertSlotReleaseOne and most of
WALInsertSlotAcquireOne() is a copied.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2014-02-10 17:04:50 | Re: proposal, patch: allow multiple plpgsql plugins |
| Previous Message | Andres Freund | 2014-02-10 16:38:06 | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |