Re: src/test/subscription/t/002_types.pl hanging on particular environment
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Craig Ringer <craig@2ndquadrant.com>,
Petr Jelinek <petr.jelinek@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-20T04:06:50Z
Lists: 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
Commits
-
Fix, or at least ameliorate, bugs in logicalrep_worker_launch().
- c1bde0747983 10.0 landed
- 3e1683d37e1d 11.0 landed
-
Fix DROP SUBSCRIPTION hang
- 8edacab20995 11.0 cited