Re: pg_restore fails with a custom backup file - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pg_restore fails with a custom backup file
Date
Msg-id 4587FAFB.6070108@dunslane.net
Whole thread Raw
In response to Re: pg_restore fails with a custom backup file  (Magnus Hagander <magnus@hagander.net>)
Responses Re: pg_restore fails with a custom backup file
Re: pg_restore fails with a custom backup file
List pgsql-hackers
Magnus Hagander wrote:
> On Tue, Dec 19, 2006 at 09:59:05PM +0900, Yoshiyuki Asaba wrote:
>   
>> Hi,
>>
>>     
>>>> Win32 does not implement fseeko() and ftello(). So I think it limit to
>>>> handle a 2GB file. Is this a specification?
>>>>         
>>> Yes, Magnus-san suggested the problem. It is present TODO.  The entire 
>>> adjustment was still difficult though I had tried it. SetFilePointer might be 
>>> able to be saved. However, I think it might be an attempt of 8.3...
>>>       
>> Is it able to use fsetpos()/fgetpos() instead of ftell()/fseek()?
>> fpos_t is a 8byte type. I tested pg_dump/pg_restore with the attached
>> patch.
>>     
>
> Hmm. Yeah, that should work in principle.
>
> However, did you test the actual backend after that change? Given where you
> change the define of off_t, that would affect every call in the backend
> that uses off_t, and it just seems very strange that you could get away
> with that without touching anything else? (If we're lucky, but I
> wouldn't count on it - there ought to be other functions in libc that we
> call that takes off_t..)
>   

I'd feel much happier if we could just patch pg_dump, since this is the 
only place we know of that we need to do large file seek/tell operations.

Did you see this from Andreas?

> MinGW has fseeko64 and ftello64 with off64_t.
>   

Maybe we need separate macros for MSVC and MinGW. Given the other 
interactions we might need to push those deep into the C files after all 
the system headers. Maybe create pg_dump_fseek.h and put them in there 
and then #include that very late.

cheers

andrew





pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: Core dump in PL/pgSQL ...
Next
From: Hans-Juergen Schoenig
Date:
Subject: Re: Core dump in PL/pgSQL ...