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

  1. Add a test framework for recovery

  2. Refactor Perl test code

  3. pgindent run for 9.5