On Sat, Feb 17, 2007 at 01:28:22PM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > I'd also like a comment from at least one other "patch reviewer" that
> > the methods used are good.
>
> It looks reasonable as far as it goes. One thought is that pg_dump
> really should h
On Sat, Feb 17, 2007 at 08:40:54PM +0100, Magnus Hagander wrote:
>
> IIRC, there was a warning from pg_dump. I don't recall exactly what, and
> don't have the space to re-run the test on my laptop here, but I think
> it was from:
> write_msg(modulename, "WARNING: ftell mismatch with expected posit
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I'd also like a comment from at least one other "patch reviewer" that
>> the methods used are good.
>
> It looks reasonable as far as it goes. One thought is that pg_dump
Ok. I'll run some more tests and then get it in.
> really
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I'd also like a comment from at least one other "patch reviewer" that
> the methods used are good.
It looks reasonable as far as it goes. One thought is that pg_dump
really should have noticed that it was writing a broken archive.
On machines where of
Yoshiyuki Asaba wrote:
> From: Magnus Hagander <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] pg_restore fails with a custom backup file
> Date: Fri, 16 Feb 2007 10:13:35 +0100
>
>> On Fri, Feb 16, 2007 at 02:09:41PM +0900, Yoshiyuki Asaba wrote:
>>
>>>>
From: Magnus Hagander <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] pg_restore fails with a custom backup file
Date: Fri, 16 Feb 2007 10:13:35 +0100
> On Fri, Feb 16, 2007 at 02:09:41PM +0900, Yoshiyuki Asaba wrote:
>
> > > > Does not compile on my MinGW - errors in the
On Fri, Feb 16, 2007 at 02:09:41PM +0900, Yoshiyuki Asaba wrote:
> > > Does not compile on my MinGW - errors in the system headers (unistd.h,
> > > io.h) due to changing the argument format for chsize(). The change of
> > > off_t propagated into parts of the system headers, thus chaos was
> > > en
Hi,
From: Magnus Hagander <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] pg_restore fails with a custom backup file
Date: Thu, 15 Feb 2007 17:38:59 +0100
> On Fri, Dec 29, 2006 at 05:30:48PM +0100, Magnus Hagander wrote:
> > On Tue, Dec 19, 2006 at 04:58:22PM +0100, Zeugswetter Andre
Hi Magnus-san.
Great!!
Although not tested yet, I seem to equip it with the tolerance to 32GB.?
P.S)
In Japan, there is a user who is employing 300GB of database on Windows2003.
I have received some problems other than this. however, this user does not permit
public presentation of the informat
On Fri, Dec 29, 2006 at 05:30:48PM +0100, Magnus Hagander wrote:
> On Tue, Dec 19, 2006 at 04:58:22PM +0100, Zeugswetter Andreas ADI SD wrote:
> >
> > > > > > MinGW has fseeko64 and ftello64 with off64_t.
> > > > > >
> > > > >
> > > > > Maybe we need separate macros for MSVC and MinGW. Given t
Thread URL added to TODO item:
o Add long file support for binary pg_dump output
---
Magnus Hagander wrote:
> On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote:
> >
> > >Win32 does not implement fseeko
Still sitting on my TODO. I have a working solution for MSVC, but it
didn't run on MingW. Andreas had a working solution on his MingW, but it
didn't work on my MingW.
I need to merge them together for something that works on all three. I
hope to have this done for 8.3, and possibly a 8.2.x, but wil
Where are we on this?
---
Magnus Hagander wrote:
> On Tue, Dec 19, 2006 at 04:58:22PM +0100, Zeugswetter Andreas ADI SD wrote:
> >
> > > > > > MinGW has fseeko64 and ftello64 with off64_t.
> > > > > >
> > > > >
> > > >
On Tue, Dec 19, 2006 at 04:58:22PM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > > > > MinGW has fseeko64 and ftello64 with off64_t.
> > > > >
> > > >
> > > > Maybe we need separate macros for MSVC and MinGW. Given the other
> > >
> > > You mean something quick and dirty like this ? That wo
Hi Asaba-san.
From: "Yoshiyuki Asaba"
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.
I'm sorry the response ..slowly...my machine reacts for the reasons of
poverty late. Last night.. I was actuall
Andrew Dunstan wrote:
> Magnus Hagander wrote:
>> 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 o
Magnus Hagander wrote:
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
datastr
> > > > MinGW has fseeko64 and ftello64 with off64_t.
> > > >
> > >
> > > Maybe we need separate macros for MSVC and MinGW. Given the other
> >
> > You mean something quick and dirty like this ? That would work.
>
> Yes, except does that actually work? If so you found the place in the
> hea
On Tue, Dec 19, 2006 at 04:25:18PM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > 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
>
> You mean something quick and dirty lik
> 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
You mean something quick and dirty like this ? That would work.
Andreas
pg_dump_fseeko64.patch
Description: pg_dump_fseeko64.patc
> >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
>
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
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 wa
Hi,
From: "Hiroshi Saito" <[EMAIL PROTECTED]>
Subject: Re: [HACKERS] pg_restore fails with a custom backup file
Date: Fri, 15 Dec 2006 00:57:50 +0900
> > Win32 does not implement fseeko() and ftello(). So I think it limit to
> > handle a 2GB file. Is this a specifi
> > I suspect we might need to create a pg_off_t type or some
> such gadget.
> >
> > Bleah.
> >
> > But it does need to be fixed.
>
> Bummer. That might be what's needed, but I'm going to at least try to
> find some neater way first. I wonder why it didn't happen on MSVC...
I don't see how th
Magnus Hagander wrote:
Also, it compiles fine on MSVC. I still haven't managed to get the MingW
build environment working properly on Win64 even for building Win32
apps, so I haven't been able to build it on MingW yet. It *should* work
since it's all standard functions, but might require further
Magnus Hagander wrote:
> > I'll try to take a look at this sometime the next couple of days (out of
> > time for today) unless beaten to it.
> >
>
> Actually, there's another option that Hiroshi mentioned off-list, that I
> forgot.
>
> We can implement the Microsoft functions _fseeki64() and _ft
Magnus Hagander wrote:
>>> Hmm. This was even worse than I thought :-(
>>>
>>> I got it building most of the way by following Andrews suggestion and
>>> greating a pgoff_t, just to check it out. That done, it seems that mingw
>>> doesn't include these 64-bit functions in their import library *at al
>> Hmm. This was even worse than I thought :-(
>>
>> I got it building most of the way by following Andrews suggestion and
>> greating a pgoff_t, just to check it out. That done, it seems that mingw
>> doesn't include these 64-bit functions in their import library *at all*.
>> That gives us basical
Magnus Hagander wrote:
I suspect we might need to create a pg_off_t type or some such gadget.
Bleah.
But it does need to be fixed.
Bummer. That might be what's needed, but I'm going to at least try to
find some neater way first. I wonder why it didn't happen on MSVC...
Hmm. This
>> I suspect we might need to create a pg_off_t type or some such gadget.
>>
>> Bleah.
>>
>> But it does need to be fixed.
>
> Bummer. That might be what's needed, but I'm going to at least try to
> find some neater way first. I wonder why it didn't happen on MSVC...
Hmm. This was even worse than
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Andrew Dunstan wrote:
>>> I suspect we might need to create a pg_off_t type or some such gadget.
>>> Bleah.
>
>> Bummer. That might be what's needed, but I'm going to at least try to
>> find some neater way first. I wonder why it did
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> I suspect we might need to create a pg_off_t type or some such gadget.
>> Bleah.
> Bummer. That might be what's needed, but I'm going to at least try to
> find some neater way first. I wonder why it didn't happen on MSVC...
Se
Andrew Dunstan wrote:
> Magnus Hagander wrote:
>> Index: src/bin/pg_dump/pg_dump.h
>> ===
>> RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.h,v
>> retrieving revision 1.130
>> diff -c -r1.130 pg_dump.h
>> *** src/bin/pg_dump
Magnus Hagander wrote:
Index: src/bin/pg_dump/pg_dump.h
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.h,v
retrieving revision 1.130
diff -c -r1.130 pg_dump.h
*** src/bin/pg_dump/pg_dump.h 9 Oct 2006 23:36:59 -
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Not so: consider a backend COPY reading or writing a multi-gig table.
>
> > Good point --- but do we do any seeks in COPY files? I don't think so,
>
> True, so if the problem is limited to whether we can seek or
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not so: consider a backend COPY reading or writing a multi-gig table.
> Good point --- but do we do any seeks in COPY files? I don't think so,
True, so if the problem is limited to whether we can seek or not, then
we don't need to fi
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> A question though - is there any *gain* from using 64-bit offsets in the
> >> actual backend? The change could of course be done in port.h, but that
>
> > No, not really. All files are kept < 1gig for the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> A question though - is there any *gain* from using 64-bit offsets in the
>> actual backend? The change could of course be done in port.h, but that
> No, not really. All files are kept < 1gig for the backend.
Not so: consider a
On Mon, Dec 18, 2006 at 09:50:12AM -0500, Bruce Momjian wrote:
> > > 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 o
Hi.
Oh, your great trust confidence.:-)
I have the fix made for just bin/pg_dump for now (in pg_dump.h), and I'm
testing that. (So far only on MSVC builds)
However, MinGW+gcc be able to be saved?
I was wishing it
Regards,
Hiroshi Saito
---(end of broadcast)-
Magnus Hagander wrote:
> On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote:
> >
> > >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
On Fri, Dec 15, 2006 at 12:57:50AM +0900, Hiroshi Saito wrote:
>
> >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 th
Hi. Asaba-san.
From: "Yoshiyuki Asaba"
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. SetFilePoint
44 matches
Mail list logo
