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)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Davinder Singh <davinder(dot)singh(at)enterprisedb(dot)com>, Dilip Kumar <dilip(dot)kumar(at)enterprisedb(dot)com>
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: 2024-12-03 18:04:29
Message-ID: CA+TgmoYVy3Z7F2bfBNmRch2gx1cL46-PjjBUVbc8EjdAvmfoAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 22, 2024 at 6:44 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Malakhov 2024-12-03 18:24:37 Precheck to consider path costs for partial paths
Previous Message Tom Lane 2024-12-03 18:01:29 Re: Better error message when --single is not the first arg to postgres executable