From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: src/test/subscription/t/002_types.pl hanging on particular environment |
Date: | 2017-09-20 03:53:53 |
Message-ID: | 15034.1505879633@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 19 September 2017 at 18:04, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-09-20 04:06:50 | Re: src/test/subscription/t/002_types.pl hanging on particular environment |
Previous Message | Amit Kapila | 2017-09-20 03:49:01 | Re: Setting pd_lower in GIN metapage |