Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Robert Haas
On Mon, Apr 18, 2016 at 11:53 AM, Robert Haas wrote: > On Mon, Apr 18, 2016 at 11:34 AM, Tom Lane wrote: >> Andres Freund writes: >>> On 2016-04-18 11:24:07 -0400, Tom Lane wrote: (The thing that gave me pause about this was noticing that I could not start two such postmasters concurre

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Robert Haas
On Mon, Apr 18, 2016 at 11:34 AM, Tom Lane wrote: > Andres Freund writes: >> On 2016-04-18 11:24:07 -0400, Tom Lane wrote: >>> (The thing that gave me pause about this was noticing that I could not >>> start two such postmasters concurrently on my RHEL6 box, without changing >>> the default syste

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Tom Lane
Andres Freund writes: > On 2016-04-18 11:24:07 -0400, Tom Lane wrote: >> (The thing that gave me pause about this was noticing that I could not >> start two such postmasters concurrently on my RHEL6 box, without changing >> the default system limits on number of SysV semaphores.) > Hm, is that di

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Robert Haas
On Mon, Apr 18, 2016 at 11:24 AM, Tom Lane wrote: > Andres Freund writes: >> On 2016-04-18 11:07:08 -0400, Tom Lane wrote: >>> Did you want to actually review this patch, or should I just push it? > >> No, I'm good, you should push it. I did a quick scan of the patch, and >> it looks sane. For a

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Andres Freund
On 2016-04-18 11:24:07 -0400, Tom Lane wrote: > (The thing that gave me pause about this was noticing that I could not > start two such postmasters concurrently on my RHEL6 box, without changing > the default system limits on number of SysV semaphores.) Hm, is that different before/after the patch

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Tom Lane
Andres Freund writes: > On 2016-04-18 11:07:08 -0400, Tom Lane wrote: >> Did you want to actually review this patch, or should I just push it? > No, I'm good, you should push it. I did a quick scan of the patch, and > it looks sane. For a second I was concerned that there might be a > situation i

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Andres Freund
On 2016-04-18 11:07:08 -0400, Tom Lane wrote: > Andres Freund writes: > > On April 16, 2016 6:02:39 PM PDT, Tom Lane wrote: > >> I went ahead and prepared and tested such a patch; the version for 9.3 > >> is attached. (9.2 is identical modulo some pgindent-induced whitespace > >> difference.) T

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-18 Thread Tom Lane
Andres Freund writes: > On April 16, 2016 6:02:39 PM PDT, Tom Lane wrote: >> I went ahead and prepared and tested such a patch; the version for 9.3 >> is attached. (9.2 is identical modulo some pgindent-induced whitespace >> difference.) This doesn't look too hazardous to me, so I'm thinking >>

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-16 Thread Andres Freund
On April 16, 2016 6:02:39 PM PDT, Tom Lane wrote: >I wrote: >> 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 >>

Re: [HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-16 Thread Tom Lane
I wrote: > 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 lac

[HACKERS] Spinlocks and semaphores in 9.2 and 9.3

2016-04-16 Thread Tom Lane
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