Bruce Momjian wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have to make sure MinGW handles it.
Wouldn't it
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >> While Win32 supports 64-bit files, the MinGW API does not,
> >> meaning we have to build an fseeko replacement on top of the
> >> Win32 API, and we have to make sure MinGW handles it.
> >>
> >>
> >
> >Wouldn't it b
Tom Lane wrote:
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have to make sure MinGW handles it.
Wouldn't it be better to lobby the MinGW folk to fix their problem?
Or
Bruce Momjian writes:
> Added to TODO:
> o Add long file support for binary pg_dump output
> While Win32 supports 64-bit files, the MinGW API does not,
> meaning we have to build an fseeko replacement on top of the
> Win32 API, and we have to make sure MinGW
Added to TODO:
o Add long file support for binary pg_dump output
While Win32 supports 64-bit files, the MinGW API does not,
meaning we have to build an fseeko replacement on top of the
Win32 API, and we have to make sure MinGW handles it.
-
Bruce Momjian wrote:
Andrew Dunstan wrote:
There is no fseeko in the Windows libraries, nor any provision in the
mingw headers that I can see for a 64 bit off_t. So we would need to
roll our own to some extent - I think we need more than just a bit of
configure cleverness.
However, the
Andrew Dunstan wrote:
> There is no fseeko in the Windows libraries, nor any provision in the
> mingw headers that I can see for a 64 bit off_t. So we would need to
> roll our own to some extent - I think we need more than just a bit of
> configure cleverness.
>
> However, there is a Windows li
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
There is no fseeko in the Windows libraries, nor any provision in the
mingw headers that I can see for a 64 bit off_t. So we would need to
roll our own to some extent - I think we need more than just a bit of
configure cleverness
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> There is no fseeko in the Windows libraries, nor any provision in the
> mingw headers that I can see for a 64 bit off_t. So we would need to
> roll our own to some extent - I think we need more than just a bit of
> configure cleverness.
> However, th
Magnus Hagander wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Hmm. Windows reports an offset size of 4 bytes on a dump I
just made
... is that relevant? What governs it?
[ looks again... ] Hm, that is a 40Gb dump Kevin is
complaining of,
is
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >> Hmm. Windows reports an offset size of 4 bytes on a dump I
> just made
> >> ... is that relevant? What governs it?
> >
> > [ looks again... ] Hm, that is a 40Gb dump Kevin is
> complaining of,
> > isn't it. Do our Windows builds have LARGEF
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Hmm. Windows reports an offset size of 4 bytes on a dump I just made
>> ... is that relevant? What governs it?
>
> [ looks again... ] Hm, that is a 40Gb dump Kevin is complaining of,
> isn't it. Do our Windows builds have LARGEFILE s
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Hmm. Windows reports an offset size of 4 bytes on a dump I just made ...
> is that relevant? What governs it?
[ looks again... ] Hm, that is a 40Gb dump Kevin is complaining of,
isn't it. Do our Windows builds have LARGEFILE support?
Hmm. Windows reports an offset size of 4 bytes on a dump I just made ...
is that relevant? What governs it?
cheers
andrew
Kevin Grittner wrote:
Posting here because it may be a 8.1 pre-release problem. I'll take
it to the admin list if it looks like it's not.
File dumped from 8.1beta3 us
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> File dumped from 8.1beta3 using pg_dump -Fc on Linux box.
> This dump restored successfully onto 8.1RC1 on Linux box.
> File FTP'd to Windows box; attempt to restore onto 8.1RC1 fails with:
> pg_restore [archiver] file offset in dump file is too large
Posting here because it may be a 8.1 pre-release problem. I'll take
it to the admin list if it looks like it's not.
File dumped from 8.1beta3 using pg_dump -Fc on Linux box.
This dump restored successfully onto 8.1RC1 on Linux box.
File FTP'd to Windows box; attempt to restore onto 8.1RC1 fails w
16 matches
Mail list logo