I wrote: > But that doesn't really detract from my point, which is that it's > totally silly for us to imagine that char and word-wide atomic ops are > interchangeable on all platforms and we can flip a coin to decide which > to use as long as the configure probes don't fail outright. Even given > working code for the byte case, we ought to prefer int atomics on PPC. > On other platforms, maybe the preference goes the other way. I'd be > inclined to follow the hard-won knowledge embedded in s_lock.h about > which to prefer.
After further study, I'm inclined to just propose that we flip the default width of pg_atomic_flag in generic-gcc.h: use int not char if both are available. The only modern platform where that's the wrong thing is x86, and that case is irrelevant here because we'll be using arch-x86.h not generic-gcc.h. A survey of s_lock.h shows that we prefer char-width slock_t only on these architectures: x86 sparc (but not sparcv9, there we use int) m68k vax So basically, the existing coding is optimizing for obsolete hardware, and not even very much of that. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers