On Sat, Jul 7, 2012 at 9:17 PM, Satoshi Nagayasu <sn...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
