Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity. |
Дата | |
Msg-id | 16488.1483654050@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity. |
Список | pgsql-hackers |
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? regards, tom lane
В списке pgsql-hackers по дате отправления: