On Thu, Jan 5, 2017 at 10:23 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Dec 27, 2016 at 9:28 PM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro >> <thomas.mu...@enterprisedb.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.
The way I proposed makes it a lot easier to work with dynamic names so you can differentiate variable numbers of areas; the names would have exactly the right extent and they'd get unregistered in each backend at just the right time. On the other hand, I don't really like seeing lock tranche stuff leaking into other APIs like this, and using tranche IDs in any way other than allocating a small number of them at startup isn't really supported anyway, so +1 for doing it your way. At one stage I had an idea that that argument was naming the DSA area, not the lock tranche, and then the lock tranche happened to use a name that was built from that name, but that doesn't make any sense if it's optional depending on whether you already registered the lock tranche... - char lwlock_tranche_name[DSA_MAXLEN]; You can remove the now-unused DSA_MAXLEN macro. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
