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 information.... Then, I have asked that the information is
exhibited. ..There is no still good reply.
Regards,
Hiroshi Saito
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 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 without breaking things that I couldn't find ;-)
>
> Compiles clean without warnings on MinGW, but not tested, sorry also no
> time.
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.
I still think we need to use a pgoff_t. Will look at combining these two
approaches.
Here's a patch that tries this.
*needs more testing*. But built with this patch, I can dump and
restore a table at the end of a 10gb database without errors.
Does the method/patch seem reasonable? Anybody else who can run a couple
of tests on it?
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
