Re: Postgres perl module namespace
От | Andrew Dunstan |
---|---|
Тема | Re: Postgres perl module namespace |
Дата | |
Msg-id | 0a3f69a9-19dd-2ae9-26f7-e65daea48141@dunslane.net обсуждение исходный текст |
Ответ на | Re: Postgres perl module namespace (Mark Dilger <mark.dilger@enterprisedb.com>) |
Ответы |
Re: Postgres perl module namespace
|
Список | pgsql-hackers |
On 2022-04-18 Mo 15:46, Mark Dilger wrote: > >> On Apr 18, 2022, at 10:59 AM, Andrew Dunstan <andrew@dunslane.net> wrote: >> >> No, I think we could probably just port the whole of src/test/PostreSQL >> back if required, and have it live alongside the old modules. Each TAP >> test is a separate miracle - see comments elsewhere about port >> assignment in parallel TAP tests. > I think $last_port_assigned would need to be shared between the two modules. This global safeguard is already a bit buggy,but not sharing it between modules would be far worse. Currently, if a node which has a port assigned is stopped,and a parallel test creates a new node, this global variable prevents the new node from getting the port alreadyassigned to the old stopped node, except when port assignment wraps around. Without sharing the global, wrap-aroundneed not happen for port collisions. > > Or am I reading the code wrong? > I don't see anything at all in the current code that involves sharing $last_port_assigned (or anything else) between parallel tests. The only reason we don't get lots of collisions there is because each one starts off at a random port. If you want it shared to guarantee non-collision we will need far more infrastructure, AFAICS, but that seems quite separate from the present issue. I have some experience of managing that - the buildfarm code has some shared state, protected by bunch of locks. To the best of my knowledge. each TAP test runs in its own process, a child of prove. And that's just as well because we certainly wouldn't want other package globals (like the node list) shared. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: