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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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:07:30
Message-ID: 16488.1483654050@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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?

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Munro 2017-01-06 00:37:37 Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
Previous Message Robert Haas 2017-01-05 22:02:45 Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-01-05 22:09:44 Re: ALTER SYSTEM for pg_hba.conf
Previous Message Robert Haas 2017-01-05 22:02:45 Re: [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.