On 2019-09-04 16:59, Tom Lane wrote:
>> A related point, perhaps we should change the key printed into
>> postmaster.pid to be in hexadecimal format ("0x08x") so that it matches
>> what ipcs prints.
> Hmm, that depends on whose ipcs you use :-(. A quick survey
> of my machines says it's
>
>
I wrote:
> This still isn't committable as-is, since the test will just curl up
> and die on machines lacking IPC::SharedMem.
After a bit of research, here's a version that takes a stab at fixing
that. There may be cleaner ways to do it, but this successfully skips
the test if it can't import the
I wrote:
> Attached is a draft patch to change both shmem and sema key selection
> to be based on data directory inode rather than port.
> ...
> I'm not quite sure what's going on in src/test/recovery/t/017_shm.pl.
> As expected, the test for port number non-collision no longer sees
> a failure. A
Peter Eisentraut writes:
> I agree with this patch and the reasons for it.
OK, thanks for reviewing.
> A related point, perhaps we should change the key printed into
> postmaster.pid to be in hexadecimal format ("0x08x") so that it matches
> what ipcs prints.
Hmm, that depends on whose ipcs you
I agree with this patch and the reasons for it.
A related point, perhaps we should change the key printed into
postmaster.pid to be in hexadecimal format ("0x08x") so that it matches
what ipcs prints.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppo
Peter Eisentraut writes:
> On 2019-08-14 01:22, Tom Lane wrote:
>> Attached is a draft patch to change both shmem and sema key selection
>> to be based on data directory inode rather than port.
> For the POSIX APIs where the numbers are just converted to a string, why
> not use both -- or forget
On 2019-08-14 01:22, Tom Lane wrote:
> Attached is a draft patch to change both shmem and sema key selection
> to be based on data directory inode rather than port.
>
> I considered using "st_ino ^ st_dev", or some such, but decided that
> that would largely just make it harder to manually correla
Noah Misch writes:
> On Fri, May 10, 2019 at 04:46:40PM -0400, Tom Lane wrote:
>> Done now, but while thinking more about the issue, I had an idea: why is
>> it that we base the shmem key on the postmaster's port number, and not
>> on the data directory's inode number? Using the port number not o
On Fri, May 10, 2019 at 04:46:40PM -0400, Tom Lane wrote:
> I wrote:
> > Will go fix/backpatch in a minute.
>
> Done now, but while thinking more about the issue, I had an idea: why is
> it that we base the shmem key on the postmaster's port number, and not
> on the data directory's inode number?
I wrote:
> Will go fix/backpatch in a minute.
Done now, but while thinking more about the issue, I had an idea: why is
it that we base the shmem key on the postmaster's port number, and not
on the data directory's inode number? Using the port number not only
increases the risk of collisions (thou
Noah Misch writes:
> Looks good. That is basically a defect in commit c09850992; the race passed
> from irrelevance to relevance when that commit subjected more segments to the
> test. Thanks for diagnosing it.
The bug's far older than that, surely, since before c09850992 we treated
*any* shmat
On Thu, May 09, 2019 at 06:47:58PM -0400, Tom Lane wrote:
> I wrote:
> > However, I have a new theory, after noticing that c09850992 moved the
> > check for shm_nattch == 0. Previously, if a shmem segment had zero attach
> > count, it was unconditionally considered not-a-threat. Now, we'll try
>
I wrote:
> However, I have a new theory, after noticing that c09850992 moved the
> check for shm_nattch == 0. Previously, if a shmem segment had zero attach
> count, it was unconditionally considered not-a-threat. Now, we'll try
> shmat() anyway, and if that fails for any reason other than EACCES
I wrote:
> Noah Misch writes:
>> The odds are very high that you would not have gotten that error before that
>> commit. But if the cause matches your guess, it's not something wrong with
>> the commit ...
> Fair point.
After more study and testing, I no longer believe my original thought
about
Noah Misch writes:
> On Wed, May 08, 2019 at 02:32:46PM -0400, Tom Lane wrote:
>> Just now, while running a parallel check-world on HEAD according to the
>> same script I've been using for quite some time, one of the TAP tests
>> died during initdb:
>> performing post-bootstrap initialization ...
At Wed, 8 May 2019 22:54:14 -0700, Noah Misch wrote in
<20190509055414.gb1066...@rfd.leadboat.com>
> On Wed, May 08, 2019 at 02:32:46PM -0400, Tom Lane wrote:
> > Just now, while running a parallel check-world on HEAD according to the
> > same script I've been using for quite some time, one of th
On Wed, May 08, 2019 at 02:32:46PM -0400, Tom Lane wrote:
> Just now, while running a parallel check-world on HEAD according to the
> same script I've been using for quite some time, one of the TAP tests
> died during initdb:
>
> selecting dynamic shared memory implementation ... posix
> selecting
Just now, while running a parallel check-world on HEAD according to the
same script I've been using for quite some time, one of the TAP tests
died during initdb:
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ...
18 matches
Mail list logo
