Re: Bug in 9.6 tuplesort batch memory growth logic - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in 9.6 tuplesort batch memory growth logic
Date
Msg-id 17301.1473167875@sss.pgh.pa.us
Whole thread Raw
In response to Bug in 9.6 tuplesort batch memory growth logic  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Bug in 9.6 tuplesort batch memory growth logic  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> While working on my parallel CREATE INDEX patch, I came across a
> problem.

I took a quick look at this.  I do not follow the logic in this new bit:

+    if (availMemLessRefund <=
+        (int64) state->activeTapes * ALLOCSET_DEFAULT_INITSIZE)
+       return;

It doesn't seem to me that this limit has anything to do with anything,
and the comment claiming only that it's "noncritical" isn't helping.
If the point is to prevent the later LACKMEM check from failing, then
certainly there is something critical somewhere.  I'd rather see this
explained as "we need at least X, but we choose to require at least Y
to avoid repalloc thrashing".  And maybe the code should use Max(X,Y)
rather than blindly assuming that ALLOCSET_DEFAULT_INITSIZE exceeds
whatever the true minimum is.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: condition variables
Next
From: Michael Paquier
Date:
Subject: Re: Proposal for changes to recovery.conf API