Re: Windows pg_basebackup unable to create >2GB pg_wal.tar tarballs ("could not close file: Invalid argument" when creating pg_wal.tar of size ~ 2^31 bytes) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Windows pg_basebackup unable to create >2GB pg_wal.tar tarballs ("could not close file: Invalid argument" when creating pg_wal.tar of size ~ 2^31 bytes)
Date
Msg-id CA+TgmoYVy3Z7F2bfBNmRch2gx1cL46-PjjBUVbc8EjdAvmfoAw@mail.gmail.com
Whole thread Raw
In response to Re: Windows pg_basebackup unable to create >2GB pg_wal.tar tarballs ("could not close file: Invalid argument" when creating pg_wal.tar of size ~ 2^31 bytes)  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Windows pg_basebackup unable to create >2GB pg_wal.tar tarballs ("could not close file: Invalid argument" when creating pg_wal.tar of size ~ 2^31 bytes)
List pgsql-hackers
On Fri, Nov 22, 2024 at 6:44 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> I'm not sure if we'd ever know if we broke MinGW + msvcrt.dll in the
> back branches, ie if any computer actually existing on earth would
> ever compile and run the second branch, and if so, be used for serious
> database work and then be able to reach the failure case.  I think an
> honest but disappointing errno is probably OK in that hypothetical
> case.  It's hard to know how far to go when programming ghost
> computers.  Thoughts, anyone?

Hypothetically speaking, suppose we just used _s_chsize everywhere
i.e. we deleted the #if/#else/#endif in your example and everything
between #else and #endif. I know very little about Windows, but I
suppose what would happen is that if you tried to compile a
thus-modified version of PostgreSQL on a very old MinGW, it would fail
to compile, and if you compiled it on a newer machine and tried to run
it on an older one, you'd get the equivalent of a dynamic linker
failure when you tried to start the server. At least that's what would
happen on Linux or macOS. Would Windows postpone the failure until we
actually tried to jump to the nonexistent entrypoint?

In any case, one idea would be to adopt this approach and, if we heard
of actual failures, we could then decide that the fallback path is
needed, and if not, then we're done. Perhaps that's too relaxed an
attitude; after all, breaking the entire server in a minor release is
not great. However, if you think that systems without msvcr80.dll are
extinct in the wild, maybe it's OK. I don't know the history of these
things, but a quick Google search suggested that maybe msvcr80.dll was
part of the "Microsoft Visual C++ 2005 Redistributable Package". I
don't know if that means all Windows shipped after 2005 would have it,
but that's a long time ago.

> (Obviously an exorcism is overdue in master, working on it...)

How does what need to be done compare to the patches from Jakub and Davinder?

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Better error message when --single is not the first arg to postgres executable
Next
From: Jeff Davis
Date:
Subject: Re: simplify regular expression locale global variables