Re: Use of "long" in incremental sort code - Mailing list pgsql-hackers

From David Rowley
Subject Re: Use of "long" in incremental sort code
Date
Msg-id CAApHDvq8F=CY2Qqy6czn1+E9YaBPCLkhGMo7gSOep=NtaoGPFg@mail.gmail.com
Whole thread Raw
In response to Re: Use of "long" in incremental sort code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Use of "long" in incremental sort code  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Tue, 30 Jun 2020 at 16:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> There is a fairly widespread issue that memory-size-related GUCs and
> suchlike variables are limited to represent sizes that fit in a "long".
> Although Win64 is the *only* platform where that's an issue, maybe
> it's worth doing something about.  But we shouldn't just fix the sort
> code, if we do do something.
>
> (IOW, I don't agree with doing a fix that doesn't also fix work_mem.)

I raised it mostly because this new-to-PG13-code is making the problem worse.

If we're not going to change the in-memory fields, then shouldn't we
at least change the ones for disk space tracking?

David



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: POC: postgres_fdw insert batching
Next
From: John Naylor
Date:
Subject: Re: truncating timestamps on arbitrary intervals