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:
http://www.postgresql.org/mailpref/pgsql-hackers
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:
http://www.postgresql.org/mailpre
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 at all. The only thing that's
> critica
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 there is something cr
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 * ALLOCSET_DEFAULT_INITSIZE)
+ retu
