Re: XLogInsert scaling, revisited - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: XLogInsert scaling, revisited
Date
Msg-id 51DA96B4.2040609@vmware.com
Whole thread Raw
In response to Re: XLogInsert scaling, revisited  (Ants Aasma <ants@cybertec.at>)
Responses Re: XLogInsert scaling, revisited
List pgsql-hackers
On 08.07.2013 13:21, Ants Aasma wrote:
> On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com>  wrote:
>> Ok, I've committed this patch now. Finally, phew!
>
> Fantastic work!
>
>> I simplified the handling of xlogInsertingAt per discussion, and added the
>> memory barrier to GetXLogBuffer(). I ran again the pgbench tests I did
>> earlier with the now-committed version of the patch (except for some comment
>> changes). The results are here:
>
> I can't see a reason why a full memory barrier is needed at
> GetXLogBuffer, we just need to ensure that we read the content of the
> page after we check the end pointer from xlblocks. A read barrier is
> enough here unless there is some other undocumented interaction.

GetXLogBuffer() doesn't read the content of the page - it writes to it 
(or rather, the caller of GetXLogBarrier() does). The barrier is needed 
between reading xlblocks (to check that the buffer contains the right 
page), and writing the WAL data to the buffer. README.barrier says that 
you need a full memory barrier to separate a load and a store.

- Heikki



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Reduce maximum error in tuples estimation after vacuum.
Next
From: Andres Freund
Date:
Subject: Re: XLogInsert scaling, revisited