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

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.
Date
Msg-id 20995.1480959676@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It's not quite the same thing, because control->max_total_segment_size
> is a total of the memory used by all allocations plus the associated
> bookkeeping overhead, not the amount of memory used by a single
> allocation.

Really?  Why doesn't it start out at zero then?

Given your later argumentation, I wonder why we're trying to implement
any kind of limit at all, rather than just operating on the principle
that it's the kernel's problem to enforce a limit.  In short, maybe
removing max_total_segment_size would do fine.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: PSQL commands: \quit_if, \quit_unless
Next
From: Nico Williams
Date:
Subject: Re: Tackling JsonPath support