On 08.07.2013 13:21, Ants Aasma wrote:
On Mon, Jul 8, 2013 at 12:16 PM, Heikki Linnakangas
<hlinnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
