Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Dec 5, 2016 at 12:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> Well, if we did that, then we'd have to remove dsa_set_size_limit().
> I don't want to do that, because I think it's useful for the calling
> code to be able to ask this code to enforce a limit that may be less
> than the point at which allocations would start failing. We do that
> sort of thing all the time (e.g. work_mem, max_locks_per_transaction)
> for good reasons. Let's not re-engineer this feature now on the
> strength of "it produces a compiler warning". I think the easiest
> thing to do here is change SIZE_MAX to (Size) -1. If there are deeper
> problems that need to be addressed, we can consider those separately.
Well, that would solve my immediate problem, which is to be able to
finish the testing Heikki requested on gaur/pademelon. But I am not
terribly impressed with the concept here. For example, this bit:
/* * If the total size limit is already exceeded, then we exit early and * avoid arithmetic wraparound in the unsigned
expressionsbelow. */if (area->control->total_segment_size >= area->control->max_total_segment_size) return NULL;
is a no-op, because it's physically impossible to exceed SIZE_MAX, and
that leads me to wonder whether the claim that this test helps prevent
arithmetic overflow has any substance. 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?
regards, tom lane