This rabbit hole keeps getting deeper and deeper :-( I realized a couple days ago that it had been close to three years since I last tried building the further-back branches on my ancient HPPA box. Not so surprisingly, things were broken: commits 37de8de9e33606a0 et al had introduced use of memory barriers into 9.2 and 9.3, which up to that moment had had none, so we'd never bothered to make barrier.h actually work in those branches. I back-patched some fixes in barrier.h, which got things to compile, and then commit 44cd47c1d49655c5, which got things to actually work ... on that box anyway. I now see from the buildfarm (and can confirm locally) that 44cd47c1d49655c5 breaks builds with --disable-spinlock, because it introduces an initialization of a spinlock before the underlying PGSemaphore infrastructure can possibly get initialized.
In 9.4 and up, this works because of daa7527afc227443, which decoupled spinlocks from semaphores enough that you can do s_init_lock_sema() long before you can actually use the spinlock. Come to think of it, that commit also means that you can get away with using a spinlock you've never done initialization on at all, which is not so good. So at this point I'm not sure what to do. I could back out the back-patch of 44cd47c1d49655c5, which would mean accepting that 9.2/9.3 are broken and will never be fixed for HPPA, as well as any other architectures that use the same fallback memory barrier implementation. The lack of complaints from the field suggests that nobody would care. Or I could push forward by back-patching daa7527afc227443 (and a couple of minor follow-on cleanups). That doesn't seem particularly risky, now that 9.4's been out for awhile, but it's kind of a large back-patch to benefit architectures that apparently no actual users care about. Thoughts? Independently of that, I think we should fix the --disable-spinlock support so that a spinlock containing zero is rejected as not properly initialized. A large part of the mess here comes from the fact that HPPA is our only architecture in which zero is not the correct initialization state for a spinlock. I'd like to have some more portable method of catching failure to initialize a spinlock. I only propose doing this part in HEAD, though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers