Re: New statistics for WAL buffer dirty writes

On Wed, Aug 1, 2012 at 10:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Solving the problem for linux only, or gcc only, isn't going to get us
> to a place where we can stop volatile-izing call sites. We need to be
> sure it works for every single case supported by s_lock.h.

Yep, that's the problem all right.

> I think you may be right that using __asm__ __volatile__ in gcc
> S_UNLOCK cases would be a big step forward, but it needs more research
> to see if that's the only fix needed.

I agree, but I will note that I have done a fair bit of research on
this already, and there are definitions in storage/barrier.h for
pg_compiler_barrier() that cover gcc, icc, HP's aCC, MSVC, and Borland
C. There are probably other wacky compilers out there, though:
looking at the build farm, I see Sun Studio and sco cc as cases that
would likely need some attention. Are there any compilers not
represented in the build-farm that we'd mind breaking?

If we can get working pg_compiler_barrier() definitions for all the
compilers we care about, the rest is probably mostly a question of
going through s_lock.h and inserting compiler barriers anywhere that
they aren't already implied by the existing code.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company