From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity. |
Date: | 2017-01-06 12:47:07 |
Message-ID: | CA+TgmobvRXpf_B_+S0X8k03sx1C+--9=YV34b9BzA+G7geOjzg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Thu, Jan 5, 2017 at 5:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jan 5, 2017 at 4:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Better documentation seems required, but really the whole design seems
>>> rather wacko. Backends must agree on numeric tranche IDs, but every
>>> backend has its own copy of the tranche name? How do we even know what
>>> agreement is? And every one has to "register" every tranche ID for
>>> itself? Why in the world isn't registration done *once* and the tranche
>>> name stored in shared memory?
>
>> Well, with the original design, that wasn't feasible, because each
>> backend had to store not only the name (which was constant across all
>> backends) but also the array_base (which might not be, if the locks
>> were stored in DSM) and array_stride. Since commit
>> 3761fe3c20bb040b15f0e8da58d824631da00caa, it would be much easier to
>> do what you're proposing. It's still not without difficulties,
>> though. There are 65,536 possible tranche IDs, and allocating an
>> array of 64k pointers in shared memory would consume half a megabyte
>> of shared memory the vast majority of which would normally be
>> completely unused. So I'm not very enthused about that solution, but
>> you aren't the first person to propose it.
>
> So, um, how do we know that backend A and backend B have the same idea
> about what tranche id 37 means?
Well, if they just call C exposed functions at random with arguments
picked out of a hat, then we don't. But if they use the APIs in the
manner documented in lwlock.h, then we do:
/*
* There is another, more flexible method of obtaining lwlocks. First, call
* LWLockNewTrancheId just once to obtain a tranche ID; this allocates from
* a shared counter. Next, each individual process using the tranche should
* call LWLockRegisterTranche() to associate that tranche ID with a name.
* Finally, LWLockInitialize should be called just once per lwlock, passing
* the tranche ID as an argument.
*
* It may seem strange that each process using the tranche must register it
* separately, but dynamic shared memory segments aren't guaranteed to be
* mapped at the same address in all coordinating backends, so storing the
* registration in the main shared memory segment wouldn't work for that case.
*/
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-01-06 14:38:51 | pgsql: Repair commit b81b5a96f424531b97cdd1dba97d9d1b9c9d372e. |
Previous Message | Thomas Munro | 2017-01-06 00:37:37 | Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity. |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2017-01-06 12:50:56 | Re: Support for pg_receivexlog --post-segment command |
Previous Message | Feike Steenbergen | 2017-01-06 12:45:09 | Support for pg_receivexlog --post-segment command |