From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Amir Rohan <amir(dot)rohan(at)mail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <gsmith(at)gregsmith(dot)com> |
Subject: | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Date: | 2015-10-06 20:58:08 |
Message-ID: | CA+TgmoarKM_QzAQr=YV4FVFDGOLMMrqjKf5xVhW-gH7w-g5e3Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Oct 3, 2015 at 7:38 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-10-06 21:01:06 | Re: Obsolete comment in tidpath.c |
Previous Message | Robert Haas | 2015-10-06 20:49:58 | Re: check fails on Fedora 23 |