Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
От | Amir Rohan |
---|---|
Тема | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
Дата | |
Msg-id | 560FD26D.6050307@zoho.com обсуждение исходный текст |
Ответ на | Re: In-core regression tests for replication, cascading, archiving, PITR, etc. (Amir Rohan <amir.rohan@zoho.com>) |
Список | 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 по дате отправления: