Alvaro Herrera wrote:
Well, duh, the checking is actually pretty simple. We just try to
connect with psql to the candidate port number before starting our own
postmaster and see if anyone is already there.
But what if something else is using the port? I think you could attempt
a bare conne
Peter Eisentraut wrote:
> Peter Eisentraut wrote:
>> Alvaro Herrera wrote:
>>> Is it possible to make it retry in case the chosen port is busy? I
>>> guess a simple check should suffice, ignoring the obvious race condition
>>> that someone uses the port after you checked it was OK.
>>
>> Well, the
Peter Eisentraut wrote:
Alvaro Herrera wrote:
Is it possible to make it retry in case the chosen port is busy? I
guess a simple check should suffice, ignoring the obvious race condition
that someone uses the port after you checked it was OK.
Well, the whole point of this exercise was to avoid
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Then again, a simple way to avoid the issue altogether on platforms
> supporting Unix-domain sockets would be to run the test over Unix-domain
> sockets (which we do anyway) placed in a private directory. How about that?
Then the brittleness is sti
Tom Lane wrote:
I'd vote for keeping the --temp-port option but not having the Makefile
use it. Seems like it'd still be potentially useful for hand use of
pg_regress.
Sorry, I didn't document this fully. The --temp-port option appears to
be redundant with the --port option, so I figured we
Alvaro Herrera wrote:
Is it possible to make it retry in case the chosen port is busy? I
guess a simple check should suffice, ignoring the obvious race condition
that someone uses the port after you checked it was OK.
Well, the whole point of this exercise was to avoid that. If we had a
way
Tom Lane wrote:
AFAICS the only way you'd end up with a zombie postmaster is if pg_ctl
stop fails, but I'm failing to understand why that's likely to happen.
No, the zombies appear if the postmaster dies (briefly) after launch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One thing we should do is have pg_regress.c, not the Makefile,
>> select the default port to use. The concatenate-5 behavior is
>> just not intelligent enough.
> How about something like this, constructing a port number from the
>
Peter Eisentraut wrote:
> Tom Lane wrote:
>> One thing we should do is have pg_regress.c, not the Makefile,
>> select the default port to use. The concatenate-5 behavior is
>> just not intelligent enough.
>
> How about something like this, constructing a port number from the
> version and a time
Tom Lane wrote:
One thing we should do is have pg_regress.c, not the Makefile,
select the default port to use. The concatenate-5 behavior is
just not intelligent enough.
How about something like this, constructing a port number from the
version and a timestamp? We could also take 2 more bits
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I played around a little with signal handling to collect the dying
> postmaster and report and error; see attached rough patch. I'm not
> exactly understanding how this works though. I would expect lots of
> psql zombies for example, because those
Peter Eisentraut wrote:
== removing existing temp installation==
== creating temporary installation==
== initializing database system ==
== starting postmaster
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> For some historic reasons, I have my local scripts set up so that they
> build development instances using the hardcoded port 65432. This will
> cause a temp install regression test to attempt to use port 565432 which
> will be rejected silently by
Peter Eisentraut wrote:
So even if I configured my local scripts to use ports that are all
different from each other and from 65432, this problem would still exist.
Only if you choose the private port to be above . The standard
buildfarm config file contains a warning against using suc
I have experienced some brittleness in the regression test setup that
causes the tests to be run against a different server instance or fail
in confusing ways when you have multiple instances running.
For some historic reasons, I have my local scripts set up so that they
build development inst
15 matches
Mail list logo
