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

From Ashutosh Sharma
Subject Should we represent temp files as unsigned long int instead of signed long int type?
Date
Msg-id CAE9k0PkzN-GKYixiah3LY9BM5+kpFHew3oGXvTADMLW7Phas2Q@mail.gmail.com
Whole thread Raw
Responses Re: Should we represent temp files as unsigned long int instead of signed long int type?
Re: Should we represent temp files as unsigned long int instead of signed long int type?
List pgsql-hackers
Hi All,

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.

Just adding few lines of code related to this from postmaster.c:

/*
 * Number of temporary files opened during the current session;
 * this is used in generation of tempfile names.
 */
static long tempFileCounter = 0;

    /*
     * Generate a tempfile name that should be unique within the current
     * database instance.
     */
    snprintf(tempfilepath, sizeof(tempfilepath), "%s/%s%d.%ld",
             tempdirpath, PG_TEMP_FILE_PREFIX, MyProcPid, tempFileCounter++);

--
With Regards,
Ashutosh Sharma.



pgsql-hackers by date:

Previous
From: Nikita Malakhov
Date:
Subject: Re: remaining sql/json patches
Next
From: Robert Haas
Date:
Subject: Re: trying again to get incremental backup