Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment |
Дата | |
Msg-id | CAA4eK1+qdqxC44pJAHmeCouwKNhWyzE2wN=KW4iEwSuLSRfc=Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] src/test/subscription/t/002_types.pl hanging on particular environment (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] src/test/subscription/t/002_types.pl hanging onparticular environment
|
Список | pgsql-hackers |
On Wed, Sep 20, 2017 at 9:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Craig Ringer <craig@2ndquadrant.com> writes: >> On 19 September 2017 at 18:04, Petr Jelinek <petr.jelinek@2ndquadrant.com> >> wrote: >>> If you are asking why they are not identified by the >>> BackgroundWorkerHandle, then it's because it's private struct and can't >>> be shared with other processes so there is no way to link the logical >>> worker info with bgworker directly. > >> I really want BackgroundWorkerHandle to be public, strong +1 from me. > > I'm confused about what you think that would accomplish. AFAICS, the > point of BackgroundWorkerHandle is to allow the creator/requestor of > a bgworker to verify whether or not the slot in question is still > "owned" by its request. > Right, but can we avoid maintaining additional information (in_use, generation,..) in LogicalRepWorker which is similar to bgworker worker machinery (which in turn can also avoid all the housekeeping for those variables) if we have access to BackgroundWorkerHandle? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: