Hi Magnus-san.

Although not tested yet, I seem to equip it with the tolerance to 32GB.?

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

I still think we need to use a pgoff_t. Will look at combining these two

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?


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

Reply via email to