Re: In-core regression tests for replication, cascading, archiving, PITR, etc. - Mailing list pgsql-hackers

From Amir Rohan
Subject Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Date
Msg-id 560FD26D.6050307@zoho.com
Whole thread Raw
In response to Re: In-core regression tests for replication, cascading, archiving, PITR, etc.  (Amir Rohan <amir.rohan@zoho.com>)
List 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




pgsql-hackers by date:

Previous
From: Amir Rohan
Date:
Subject: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Next
From: Andres Freund
Date:
Subject: Re: ON CONFLICT DO UPDATE using EXCLUDED.column gives an error about mismatched types