Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.
Date
Msg-id CA+TgmoZc0Qe1L1ShPNcwhZXbn5Xat=JMadpvzKULhshq5YAdbA@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 5, 2016 at 2:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Dec 5, 2016 at 1:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Also, given that the idea of
>>> DSA seems to be to support a number of different use-cases, I'm not
>>> sure that it's useful to have a knob that limits the total consumption
>>> rather than individual areas.  IOW: who exactly is going to call
>>> dsa_set_size_limit, and on what grounds would they compute the limit?
>
>> The code that creates the DSA is going to call it.
>
> Ah, I misunderstood: from the name of the field and the way you'd
> described it, I thought it was a limit on the total space used across
> all DSAs.  A per-DSA limit does make sense.

OK, good.  I was rather puzzled as to how that didn't seem like a good
thing to have available.  I'm going to go change SIZE_MAX to (Size) -1
now and we can decide later if something else should be done.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Creating a DSA area to provide work space for parallel execution
Next
From: David Fetter
Date:
Subject: Re: Separate connection handling from backends