Re: [HACKERS] Bug in 9.6 tuplesort batch memory growth logic

On Tue, Sep 6, 2016 at 12:51 PM, Tom Lane wrote: > I rewrote the comment and pushed it. Thank you. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Bug in 9.6 tuplesort batch memory growth logic

I wrote: > I see. The comment could do with a bit of rewriting, perhaps. I rewrote the comment and pushed it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Bug in 9.6 tuplesort batch memory growth logic

Peter Geoghegan writes: > On Tue, Sep 6, 2016 at 6:17 AM, Tom Lane wrote: >> 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. > You've not understood the problem

Re: [HACKERS] Bug in 9.6 tuplesort batch memory growth logic

On Tue, Sep 6, 2016 at 6:17 AM, Tom Lane wrote: > 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

Re: [HACKERS] Bug in 9.6 tuplesort batch memory growth logic

Peter Geoghegan 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 *

[HACKERS] Bug in 9.6 tuplesort batch memory growth logic

While working on my parallel CREATE INDEX patch, I came across a problem. I initially assumed that what I saw was just a bug in my development branch. During a final merge in a parallel worker, with very little maintenance_work_mem, workers attempted to allocate an amount of memory slightly less