Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity. |
Дата | |
Msg-id | CA+TgmobvRXpf_B_+S0X8k03sx1C+--9=YV34b9BzA+G7geOjzg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Jan 5, 2017 at 5:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Jan 5, 2017 at 4:33 PM, Tom Lane <tgl@sss.pgh.pa.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 trancheID; 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 perlwlock, passing* the tranche ID as an argument.** It may seem strange that each process using the tranche must registerit* separately, but dynamic shared memory segments aren't guaranteed to be* mapped at the same address in all coordinatingbackends, 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
В списке pgsql-hackers по дате отправления: