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

From Magnus Hagander
Subject Re: pg_restore fails with a custom backup file
Date
Msg-id 20061219150755.GA10611@svr2.hagander.net
Whole thread Raw
In response to Re: pg_restore fails with a custom backup file  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_restore fails with a custom backup file
List pgsql-hackers
> >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.

My thoughts exactly.

> 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.

We need different macrosand possibly functions, yes.
I think I got enough patched at home last night to get it working with
this, I was just too focused on one set of macros at the time. It's not
enough to include them very late - because off_t is used in the shared
datastructures in pg_dump/etc. It is possible to localise it to the
pg_dump binaries, though, given some header redirection *and* given that
we change all those off_t to pgoff_t (or similar). I couldn't find a way
to do it without changing the off_t define.

I'll try to take a look at merging these two efforts (again unless
beaten to it, have to do some of that dreaded christmas shopping as
well...)

//Magnus


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] Enums patch v2
Next
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] Enums patch v2