Re: src/test/subscription/t/002_types.pl hanging on particular environment
Petr Jelinek <petr.jelinek@2ndquadrant.com>
From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Craig Ringer <craig@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Thomas Munro <thomas.munro@enterprisedb.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-20T10:59:41Z
Lists: pgsql-hackers
On 20/09/17 05:53, Tom Lane 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. This is necessarily not useful to any other > process, since they didn't make the request. I works pretty well as unique identifier of the bgworker which can be used to check if the specific bgworker process is the one we think it is and that would work even across processes if it could be shared. Bgworker slots don't help with that as they can be replaced by different worker between calls, same goes for PID. It technically does not have to be public struct, just serialize-able/copyable so knowing size of the struct ought to be enough for that. > 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. > Well, that would be nice but those slots are in shared memory so it's not exactly easy to allow other modules to add arbitrary data there. Maybe we could add just one field that holds DSM handle (or DSA handle) to whatever dynamic shared memory is allocated for that slot. I don't know enough about inner working of DSM to say for sure if that's feasible or not though. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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