Re: Use of "long" in incremental sort code
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: James Coleman <jtc331@gmail.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-30T04:24:00Z
Lists: 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
Commits
-
Use int64 instead of long in incremental sort code
- 6ee3b5fb990e 14.0 landed
- 22c105595fc7 13.0 landed