Thomas Munro writes:
> On Tue, Oct 11, 2016 at 5:57 AM, Tom Lane wrote:
>> (I'm a little suspicious that older variants of FreeBSD might not
>> have working sem_init, like the other *BSD variants, necessitating
>> a run-time test there. But we'll cross that bridge when we come
>> to it.)
> The
On Tue, Oct 11, 2016 at 5:57 AM, Tom Lane wrote:
> So at this point it seems likely that stopping with Linux and FreeBSD
> is the thing to do, and as far as I can tell the code we have now is
> working with all variants of those that we have in the buildfarm.
> (I'm a little suspicious that older
Christoph Berg writes:
> Another data point that's admittedly much more of a footnote than
> serious input to the original question is the following: Debian has a
> (so far mostly toy) port "hurd-i386" which is using the GNU hurd
> kernel along with the usual GNU userland that's also in use on Lin
Re: Tom Lane 2016-10-08 <29244.1475959...@sss.pgh.pa.us>
> So I'm still of the opinion that there's not likely to be any meaningful
> performance difference in practice, at least not on reasonably recent
> Linux machines. But this does indicate that if there is any difference,
> it will probably f
Robert Haas writes:
> On Thu, Oct 6, 2016 at 9:46 AM, Tom Lane wrote:
>> Can anyone think of a test case that would stress semaphore operations
>> more heavily, without being unrealistic?
> I think it's going to be pretty hard to come up with a non-artificial
> test case that has exhibits meanin
On Thu, Oct 6, 2016 at 5:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> Alternatively, get a bigger box. :-)
>
> So what's it take to get access to hydra?
Send me a private email with your .ssh key.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas writes:
> Alternatively, get a bigger box. :-)
So what's it take to get access to hydra?
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-
On Thu, Oct 6, 2016 at 9:46 AM, Tom Lane wrote:
> Can anyone think of a test case that would stress semaphore operations
> more heavily, without being unrealistic?
I think it's going to be pretty hard to come up with a non-artificial
test case that has exhibits meaningful lwlock contention on an
I wrote:
> Although in normal cases the semaphore code paths aren't very heavily
> exercised in our code, I was able to get a measurable performance
> difference by building with --disable-spinlocks, so that spinlocks are
> emulated with semaphores. On an 8-core RHEL6 machine, "pgbench -S -c 20
>
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
> I've gotten a bit tired of seeing "could not create semaphores: No space
> left on device" failures in the buildfarm, so I looked into whether we should
> consider preferring unnamed POSIX
I've gotten a bit tired of seeing "could not create semaphores: No space
left on device" failures in the buildfarm, so I looked into whether we
should consider preferring unnamed POSIX semaphores over SysV semaphores.
We've had code for named and unnamed POSIX semaphores in our tree for
a long tim
11 matches
Mail list logo
