Re: New statistics for WAL buffer dirty writes - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: New statistics for WAL buffer dirty writes
Date
Msg-id CAMkU=1xFFaonqsVm66QFE-jvirrKw4ug8Xbb-NdUXUaM-C5N7w@mail.gmail.com
Whole thread Raw
In response to Re: New statistics for WAL buffer dirty writes  (Satoshi Nagayasu <snaga@uptime.jp>)
Responses Re: New statistics for WAL buffer dirty writes  (Robert Haas <robertmhaas@gmail.com>)
Re: New statistics for WAL buffer dirty writes  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Sat, Jul 7, 2012 at 9:17 PM, Satoshi Nagayasu <snaga@uptime.jp> wrote:
> Hi,
>
> Jeff Janes has pointed out that my previous patch could hold
> a number of the dirty writes only in single local backend, and
> it could not hold all over the cluster, because the counter
> was allocated in the local process memory.
>
> That's true, and I have fixed it with moving the counter into
> the shared memory, as a member of XLogCtlWrite, to keep total
> dirty writes in the cluster.

A concern I have is whether the XLogCtlWrite *Write pointer needs to
be declared volatile, to prevent the compiler from pushing operations
on them outside of the locks (and so memory barriers) that formally
protect them.  However I see that existing code with Insert also does
not use volatile, so maybe my concern is baseless.  Perhaps the
compiler guarantees to not move operations on pointers over the
boundaries of function calls?  The pattern elsewhere in the code seems
to be to use volatiles for things protected by spin-locks (implemented
by macros) but not for things protected by LWLocks.

The comment "XLogCtrlWrite must be protected with WALWriteLock"
mis-spells XLogCtlWrite.

The final patch will need to add a sections to the documentation.

Cheers,

Jeff


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree
Next
From: Tom Lane
Date:
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree