Re: Should we represent temp files as unsigned long int instead of signed long int type? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should we represent temp files as unsigned long int instead of signed long int type?
Date
Msg-id CA+TgmoadtuWVx6LupFcvXF-t3sLfjDk278iL9-ubR0m4==Lw9g@mail.gmail.com
Whole thread Raw
In response to Should we represent temp files as unsigned long int instead of signed long int type?  (Ashutosh Sharma <ashu.coek88@gmail.com>)
List pgsql-hackers
On Wed, Oct 25, 2023 at 1:28 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> At present, we represent temp files as a signed long int number. And
> depending on the system architecture (32 bit or 64 bit), the range of
> signed long int varies, for example on a 32-bit system it will range
> from -2,147,483,648 to 2,147,483,647. AFAIU, this will not allow a
> session to create more than 2 billion temporary files and that is not
> a small number at all, but still what if we make it an unsigned long
> int which will allow a session to create 4 billion temporary files if
> needed. I might be sounding a little stupid here because 2 billion
> temporary files is like 2000 peta bytes (2 billion * 1GB), considering
> each temp file is 1GB in size which is not a small data size at all,
> it is a huge amount of data storage. However, since the variable we
> use to name temporary files is a static long int (static long
> tempFileCounter = 0;), there is a possibility that this number will
> get exhausted soon if the same session is trying to create too many
> temp files via multiple queries.

I think we use signed integer types in a bunch of places where an
unsigned integer type would be straight-up better, and this is one of
them.

I don't know whether it really matters, though.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Should we represent temp files as unsigned long int instead of signed long int type?
Next
From: Andrew Dunstan
Date:
Subject: Re: trying again to get incremental backup