Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
Date
Msg-id 52F910FF.2050300@vmware.com
Whole thread Raw
In response to Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
List pgsql-hackers
On 02/10/2014 06:41 PM, Andres Freund wrote:
> 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.

I'm not too happy with the amount of copy-paste myself, but there was 
enough difference to regular lwlocks that I didn't want to bother all 
lwlocks with the xlog-specific stuff either. The WAL insert slots do 
share the LWLock-related PGPROC fields though, and semaphore. I'm all 
ears if you have ideas on that..

- Heikki



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Next
From: Merlin Moncure
Date:
Subject: Re: jsonb and nested hstore