Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Amir Rohan <amir.rohan@zoho.com>
From: Amir Rohan <amir.rohan@zoho.com>
To: Michael Paquier <michael.paquier@gmail.com>,
Amir Rohan <amir.rohan@mail.com>
Cc: Noah Misch <noah@leadboat.com>, Andres Freund <andres@2ndquadrant.com>,
PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, gsmith@gregsmith.com
Date: 2015-10-03T13:04:45Z
Lists: pgsql-hackers
On 10/03/2015 03:50 PM, Amir Rohan wrote: > On 10/03/2015 02:38 PM, Michael Paquier wrote: >> On Fri, Oct 2, 2015 at 11:10 PM, Amir Rohan wrote: >>> On 10/02/2015 03:33 PM, Michael Paquier 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. >> > > What part of "Never assign the same port twice during one test" > makes this "not transparent to the user"? > > If you're thinking about parallel tests, I don't think you > need to worry. Availability checks take care of one part, Except now that I think of it, that's definitely a race: Thread1: is_available(5432) -> True Thread2: is_available(5432) -> True Thread1: listen(5432) -> True Thread2: listen(5432) -> #$@#$&@#$^&$#@& I don't know if parallel tests are actually supported, though. If theye are, you're right that this is a shared global resource wrt concurrency. Amir
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