Re: [HACKERS] Should logtape.c blocks be of type long?

2017-02-26 Thread Peter Geoghegan
On Sun, Feb 26, 2017 at 9:48 AM, Tom Lane wrote: > [ shrug... ] If you're excited enough about it to do the work, I won't > stand in your way. But I don't find it to be a stop-ship issue. I'll add it to my todo list for Postgres 10. I think it's worth being consistent

Re: [HACKERS] Should logtape.c blocks be of type long?

2017-02-26 Thread Tom Lane
Peter Geoghegan writes: > On Sun, Feb 26, 2017 at 9:07 AM, Tom Lane wrote: >> 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

Re: [HACKERS] Should logtape.c blocks be of type long?

2017-02-26 Thread Robert Haas
On Sun, Feb 26, 2017 at 10:37 PM, Tom Lane wrote: > 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. Is this comment a

Re: [HACKERS] Should logtape.c blocks be of type long?

2017-02-26 Thread Peter Geoghegan
On Sun, Feb 26, 2017 at 9:07 AM, Tom Lane wrote: > 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

Re: [HACKERS] Should logtape.c blocks be of type long?

2017-02-26 Thread Tom Lane
Peter Geoghegan 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

Re: [HACKERS] Should logtape.c blocks be of type long?

2017-02-26 Thread Robert Haas
On Sun, Feb 26, 2017 at 2:44 AM, Peter Geoghegan wrote: > I tend to be suspicious of use of the type "long" in general, because > in general one should assume that it is no wider than "int". This > calls into question why any code that uses "long" didn't just use > "int", at least

[HACKERS] Should logtape.c blocks be of type long?

2017-02-25 Thread Peter Geoghegan
logtape.c stores block numbers on disk. These block numbers are represented in memory as being of type long. This is why BufFile clients that use the block-based interface (currently limited to logtape.c and gistbuildbuffers.c) must live with a specific limitation, as noted within buffile.c: /*