Re: [Patch] Windows relation extension failure at 2GB and 4GB

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Bryan Green <dbryan(dot)green(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [Patch] Windows relation extension failure at 2GB and 4GB
Date: 2025-11-06 22:20:46
Message-ID: aQ0fPkOaPo4COZPf@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 06, 2025 at 11:10:00PM +1300, Thomas Munro wrote:
> Observing that mess, I kinda wonder what would happen if we just used
> a big hammer to redefine off_t to be __int64 ourselves. On the face
> of it, it sounds like an inherently bad idea that could bite you when
> interacting with libraries whose headers use off_t. On the other
> hand, the world of open source libraries we care about might already
> be resistant to that chaos, if libraries are being built with and
> without -D_FIILE_OFFSET_BITS=64 willy-nilly, or they actually can't
> deal with large files at all in which case that's something we'd have
> to deal with whatever we do. I don't know, it's just a thought that
> occurred to me while contemplating how unpleasant it is to splatter
> pgoff_t all over our tree, and yet *still* have to tread very
> carefully with the boundaries of external libraries that might be
> using off_t, researching each case...

Not sure about that. It's always been something we have tackled with
the various pg_ and PG_ structures and definitions. Not sure that
this has to apply here since we already have one pgoff_t for the
purpose of portability for quite a few years already (d00a3472cfc4).
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-11-06 22:21:40 Re: another autovacuum scheduling thread
Previous Message Michael Paquier 2025-11-06 22:13:33 Re: [Patch] Windows relation extension failure at 2GB and 4GB