Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] tables >2GB

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: darrenk(at)insightdist(dot)com (Darren King)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] tables >2GB
Date: 1998-03-20 02:47:48
Message-ID: 199803200247.VAA22860@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> > So, how about we fix the storage manager instead?
> 
> I don't recall, what exactly breaks when going over 2 gig? I don't have the
> disk space available, otherwise I'd debug this.  I can still try if I knew
> what the problem was...this code isn't all that complex.

I agree.

> OK...here is a patch that will cause the magnetic disk storage manager to
> not try to split files in 2 gig chunks.  It will just try to get another
> block.
> 
> If applied, everything is just as before. But if LET_OS_MANAGE_FILESIZE
> is defined, the chaining disappears and the file just keeps on going,
> and going, and going, til the OS barfs.
> 
> Are there #defines in the system includes that could be used to determine
> a max file size?  If so, then I'd think that this would be something
> to add to configure.  If files over 2 gig are not allowed, then the old
> code would compile.
> 
> Anyway, if the patch looks ok to the powers-that-be or if there is some
> thing else to be changed, let me know and I'll resubmit it to PATCHES.
> 
> Compiled and regressed ok with and without LET_OS_MANAGE_FILESIZE, but
> then again there aren't any regression tables over 2 gig. :)
> 

Well, BSD/OS goes over 2gig, but the postgreSQL code uses lseek, which
returns long, so even though I can handle larger files, the lseek()
can't because long is 32-bits.  Looks like only Alpha can handle those
files based on our current code.

Thanks to our success, this looks like something we will have to deal
with.


-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Responses

pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-03-20 03:27:47
Subject: Re: [HACKERS] Re: [QUESTIONS] UPDATE statement ORACLE 6 compatible
Previous:From: James HughesDate: 1998-03-20 02:17:36
Subject: Re: [HACKERS] VACUUM ANALYZE Problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group