Re: src/test/subscription/t/002_types.pl hanging on particular environment
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>,
Amit Kapila <amit.kapila16@gmail.com>,
Thomas Munro <thomas.munro@enterprisedb.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-20T03:53:53Z
Lists: pgsql-hackers
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. This is necessarily not useful to any other process, since they didn't make the request. The thought I had in mind upthread was to get rid of logicalrep slots in favor of expanding the underlying bgworker slot with some additional fields that would carry whatever extra info we need about a logicalrep worker. Such fields could also be repurposed for additional info about other kinds of bgworkers, when (not if) we find out we need that. regards, tom lane
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