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 position
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 have noticed
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 system headers (unistd.h,
io.h
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 system
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 off_t
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 should have
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
ensured.
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 the other
You
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
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 Andreas ADI SD wrote
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
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()
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.
Maybe we need separate
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 would work.
Yes,
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
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 the error
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 specification?
Yes, Magnus-san suggested
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
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
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
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.patch
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 like this ? That
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
headers to stick it
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
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 off_t is
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 actually
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 though I
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
adjustment
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
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 of 8.3...
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 backend
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 backend.
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 fix the
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 not, then
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 -
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/pg_dump.h
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...
Seems like
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 didn't happen on
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 I thought
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
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 basically two
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 all*.
That
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 _ftelli64()
Hi,
pg_restore faied by the following operations on Windows XP.
$ createdb test
$ pgbench -i -s 1000 test
$ pg_dump -Fc test out
$ createdb restore
$ pg_restore -d restore out
pg_restore: [custom archiver] error during file seek: Invalid argument
Win32 does not implement fseeko()
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.
45 matches
Mail list logo
