Re: [Patch] Windows relation extension failure at 2GB and 4GB
| От | Michael Paquier |
|---|---|
| Тема | Re: [Patch] Windows relation extension failure at 2GB and 4GB |
| Дата | |
| Msg-id | aQ0fPkOaPo4COZPf@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: [Patch] Windows relation extension failure at 2GB and 4GB (Thomas Munro <thomas.munro@gmail.com>) |
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: