On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>> Granted, you have to try fairly hard to shoot yourself in the leg,
>> but since the solution is so simple, why not? If we never reuse ports
>> within a single test, this goes away.
>
> Well, you can reuse the same port number in a test. Simply teardown
> the existing node and then recreate a new one. I think that port
> number assignment to a node should be transparent to the caller, in
> our case the perl test script holding a scenario.
It seems that these days 'make check' creates a directory in /tmp
called /tmp/pg_regress-RANDOMSTUFF. Listening on TCP ports is
disabled, and the socket goes inside this directory with a name like
.s.PGSQL.PORT. You can connect with psql -h
/tmp/pg_regress-RANDOMSTUFF -p PORT, but not over TCP. This basically
removes the risk of TCP port number collisions, as well as the risk of
your temporary instance being hijacked by a malicious user on the same
machine. I'm not sure what we do on Windows, though.
>> In particular, I was shutting down an archiving node and the archiving
>> was truncated. I *think* smart doesn't do this. But again, it's really
>> that the test writer can't easily override, not that the default is wrong.
>
> Ah, OK. Then fast is just fine. It shuts down the node correctly.
> "smart" would wait for all the current connections to finish but I am
> wondering if it currently matters here: I don't see yet a clear use
> case yet where it would make sense to have multi-threaded script... If
> somebody comes back with a clear idea here perhaps we could revisit
> that but it does not seem worth it now.
I don't have anything brilliant to say about this point, but here's a
perhaps-not-brilliant comment:
If there's a bug in one of smart and fast shutdown and the other works
great, it would be nice to catch that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
