From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should logtape.c blocks be of type long? |
Date: | 2017-02-26 17:07:45 |
Message-ID: | 11844.1488128865@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> logtape.c stores block numbers on disk. These block numbers are
> represented in memory as being of type long.
Yeah. This code is far older than our willingness to assume that every
platform can support int64, and I'm pretty sure that use of "long" was
just a compromise to get the widest values we could use portably and
without a lot of notational hassle. (There are some similar choices in
the area of memory usage, particularly calculations related to work_mem.)
Having said that, I'm not sure it's worth the trouble of changing.
The platforms where there's a difference are probably not muscular
enough that anyone would ever get past 16TB in a temp file anyhow.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2017-02-26 17:21:53 | Re: [patch] reorder tablespaces in basebackup tar stream for backup_label |
Previous Message | Robert Haas | 2017-02-26 16:55:14 | Re: [patch] reorder tablespaces in basebackup tar stream for backup_label |