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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Should logtape.c blocks be of type long?
Date: 2023-09-22 04:46:07
Message-ID: ZQ0cD0mHa0-nuFLC@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 26, 2017 at 10:04:20AM -0800, Peter Geoghegan wrote:
> I think it's worth being consistent about a restriction like this, as
> Robert said. Given that fixing this issue will not affect the machine
> code generated by compilers for the majority of platforms we support,
> doing so seems entirely worthwhile to me.

(Reviving an old thread, fives years later..)

As far as I can see, no patches have been sent to do that, and the
changes required to replace long by int64 in the logtape and tuplesort
code are rather minimal as long as some care is taken with all the
internals of logtape (correct me of course if I'm wrong). I really
don't see why we shouldn't do the switch based on the argument of
Windows not being able to handle more than 16TB worth of blocks as
things stand because of long in these code paths.

So, attached is a patch to change these longs to int64. Any thoughts?
--
Michael

Attachment Content-Type Size
logtape-int64.patch text/x-diff 14.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message 程ゆき 2023-09-22 04:49:56 Try adding type cast with tablespace
Previous Message Dilip Kumar 2023-09-22 04:03:50 Re: New WAL record to detect the checkpoint redo location