From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Andreas Seltenreich <seltenreich(at)gmx(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [sqlsmith] Crash reading pg_stat_activity |
Date: | 2017-01-04 21:23:12 |
Message-ID: | CA+TgmoaR++pDAg9KGvtT4-3OwNkY+A3ZW5M-arZ+=J803h=5XQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 27, 2016 at 9:28 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> But I'm starting to think that the best way might be to do BOTH of the
>> things I said in my previous message: make dsa.c register on
>> create/attach and also unregister before detaching iff the name was
>> supplied at creation time for the benefit of extension writers, but
>> make it not do anything at all about tranche name
>> registration/unregistration if NULL was passed in at create time.
>> Then register this particular tranche (LWTRANCHE_PARALLEL_QUERY_DSA)
>> in every process in RegisterLWLockTranches. That way, you'd get a
>> useful name in pg_stat_activity for other backends that are running
>> parallel queries if they are ever waiting for these locks (unlikely
>> but interesting to know abotu if it happens).
>
> Maybe something like the attached.
Now that array_base and array_stride are gone, I don't see any reason
why the DSA machinery needs to be aware of tranche names at all. So I
propose to rip all that out, as in the attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachment | Content-Type | Size |
---|---|---|
preregister-dsa-tranche.patch | text/x-diff | 5.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-01-04 21:32:39 | Re: [PATCH] Fix for documentation of timestamp type |
Previous Message | Simon Riggs | 2017-01-04 21:20:20 | Re: logical decoding of two-phase transactions |