Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Amir Rohan <amir.rohan@mail.com>, Noah Misch <noah@leadboat.com>,
Andres Freund <andres@2ndquadrant.com>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
Greg Smith <gsmith@gregsmith.com>
Date: 2015-10-06T20:58:08Z
Lists: pgsql-hackers
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
Commits
-
Add a test framework for recovery
- 49148645f7f3 9.6.0 landed
-
Refactor Perl test code
- 1caef31d9e55 9.6.0 cited
-
pgindent run for 9.5
- 807b9e0dff66 9.5.0 cited