On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
