Re: pgsql: Use data directory inode number, not port, to select SysV resour

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Use data directory inode number, not port, to select SysV resour
Date: 2019-09-08 21:54:12
Message-ID: a1c40fab-a38c-cb42-6879-125f834e837b@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers


On 9/6/19 3:51 PM, Andrew Dunstan wrote:
> On 9/6/19 2:42 PM, Tom Lane wrote:
>> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>>> Given your stated intention, I think the simplest way to get it is just
>>> this, without worrying about what the perl modules might do:
>>> -if ($@)
>>> +if ($@ || $windows_os)
>> WFM, do you want to push that?
>>
>>
>
> done.
>
>

[redirected to -hackers]

I'm going to disable this test (src/test/recovery/t/017_shm.pl) on
Windows on the back branches too unless there's a violent objection. The
reason is that the script runs "postgres --single" and that fails on
Windows when run by an administrative account. We've carefully enabled
postgres and its tests to run safely under an admin account. I
discovered this as part of my myss2 testing.

cheers

andrew

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2019-09-08 22:00:29 Re: pgsql: Use data directory inode number, not port, to select SysV resour
Previous Message Tom Lane 2019-09-08 21:01:20 pgsql: Fix RelationIdGetRelation calls that weren't bothering with erro

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-09-08 21:59:00 Re: MSVC buildfarm critters are not running modules' TAP tests
Previous Message Andrew Dunstan 2019-09-08 21:46:35 Re: MSVC buildfarm critters are not running modules' TAP tests