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)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Davinder Singh <davinder.singh@enterprisedb.com>, Dilip Kumar <dilip.kumar@enterprisedb.com>
Date: 2024-12-03T18:04:29Z
Lists: 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
Commits
-
Fix off_t overflow in pg_basebackup on Windows.
- bd0564f61d37 13.19 landed
- 8f40d46126a0 14.16 landed
- 6b6901a26f56 15.11 landed
- be7489662e77 16.7 landed
- faee3185aafa 17.3 landed
- 970b97eeb8f0 18.0 landed
-
Provide 64-bit ftruncate() and lseek() on Windows.
- 026762dae39d 18.0 landed
- af109e3399b6 17.3 landed
- 0bff6f1da842 16.7 landed
- 70a7a37610f7 15.11 landed
- 1636c5e56ed7 14.16 landed
- d02486cc8e0a 13.19 landed
-
Require ucrt if using MinGW.
- 1758d4244616 18.0 cited