Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.

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-05 22:02:45
Message-ID: CA+Tgmob2c4AU=PgofB0-d1uDV8vdkG7C6X7Hhkc_PwUou4ar9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Thu, Jan 5, 2017 at 4:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I suspect you're going to tell me this all needs to be better
>> documented, which is probably a valid criticism. Suggestions as to
>> where such documentation should be added - either as code comments or
>> in a README somewhere or in doc/src/sgml - will be gratefully
>> accepted.
>
> 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-01-05 22:07:30 Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
Previous Message Tom Lane 2017-01-05 21:33:40 Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-01-05 22:07:30 Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
Previous Message Robert Haas 2017-01-05 21:57:11 Re: Group clear xid can leak semaphore count