From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Jeff Davis <pgsql@j-davis.com>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Melanie Plageman <melanieplageman@gmail.com>,
        Soumyadeep Chakraborty <sochakraborty@pivotal.io>,
        Robert Haas <robertmhaas@gmail.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>, soumyadeep2007@gmail.com
Subject: Re: Memory Accounting
In-reply-to: 
 <CAH2-Wzm8Nh7Ky-OpoNYQLAg3VGjkxqjeKfnKroQ=Ppk6STvuyg@mail.gmail.com>
References: 
 <CADwEdor2jZitB2P94on2LUAhdi0iRHv2WNseV3LJmJPenuuNpw@mail.gmail.com>
 <67f66d2fa39e35aef90093c74531a38dcd5c0f73.camel@j-davis.com>
 <CAAKRu_b2Qxr=GzE7thk8_=JDgYRnOssYBuqWdZ39R2+Heo=oQw@mail.gmail.com>
 <20190926192244.mk5ru6nkofo7am3h@development>
 <57780817877d4b40106b248b63261e21a7a56261.camel@j-davis.com>
 <20190928221249.mo2jrtlakingnc5e@development>
 <20190928222206.thidzeygazl7axhg@development>
 <392e034c1b674a1a58c217dc440ea6197081ccfa.camel@j-davis.com>
 <20191001021114.iimd77xgnstaww7j@development>
 <15151.1570163761@sss.pgh.pa.us>
 <20191004082644.wytixiukkm6ditlu@development>
 <0278d32083d051f165c75d605d9fd1a82a197ef8.camel@j-davis.com>
 <CAH2-Wzm8Nh7Ky-OpoNYQLAg3VGjkxqjeKfnKroQ=Ppk6STvuyg@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Fri, 04 Oct 2019 11:43:06 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10469.1570215529.1@sss.pgh.pa.us>
Date: Fri, 04 Oct 2019 14:58:49 -0400
Message-ID: <10470.1570215529@sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Fri, Oct 4, 2019 at 7:32 AM Jeff Davis <pgsql@j-davis.com> wrote:
>> The patch has been floating around for a very long time, so I don't
>> remember exactly why I chose a signed value. Sorry.

> I am reminded of the fact that int64 is used to size buffers within
> tuplesort.c, because it needs to support negative availMem sizes --
> when huge allocations were first supported, tuplesort.c briefly used
> "Size", which didn't work. Perhaps it had something to do with that.

I wonder if we should make that use ssize_t instead.  Probably
not worth the trouble.

			regards, tom lane