On Mon, Jul 8, 2013 at 1:38 PM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > 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.
Indeed you are right. My bad. I somehow thought that every location in the WAL buffer is written once while it's actually done twice due to AdvanceXLInsertBuffer() zeroing the page out. Now thinking about it, if that memset or the full memory barrier in GetXLogBuffer() ever prove to be a significant overhead, the initialization could be optimized to avoid zeroing the page. AdvanceXLInsertBuffer() would only write the header fields, CopyXLogRecordToWAL() needs to take care to write out zeroes for alignment padding and xlog switches and always write out xlp_rem_len and XLP_FIRST_IS_CONTRECORD bit of xlp_info. xlp_info needs to be split into two 8bit variables so XLP_FIRST_IS_CONTRECORD and XLP_LONG_HEADER/XLP_BKP_REMOVABLE can be written into disjoint memory locations. This way all memory locations in xlog buffer page are stored exactly once and there is no data race between writes making it possible to omit the barrier from GetXLogBuffer. WaitXLogInsertionsToFinish() takes care of the memory barrier for XlogWrite(). Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
