Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.9.2/8.9.1) with ESMTP id LAA46633 for ; Wed, 3 Feb 1999 11:43:06 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA04820; Wed, 3 Feb 1999 11:42:02 -0500 (EST) To: Jim Carroll cc: "Jackson, DeJuan" , pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] Postgres Limitations In-reply-to: Your message of Tue, 2 Feb 1999 21:50:14 -0500 Date: Wed, 03 Feb 1999 11:42:01 -0500 Message-ID: <4818.918060121@sss.pgh.pa.us> From: Tom Lane Jim Carroll writes: >> It is currently unclear as to what will happen when you table reaches 2G >> of storage on most file systems. I think that >2G table handling got >> broken somehow. > I know this is probably a "loaded" question, but do have any idea what > might be the cause of this limitation ? Postgres does have logic for coping with tables > 2Gb by splitting them into multiple Unix files. Peter Mount recently reported that this feature appears to be broken in the current sources (cf hackers mail list archive for 25/Jan/99). I don't think anyone has followed up on the issue yet. (I dunno about the other developers, but I don't have a few Gb of free space to spare so I can't test it...) You could make a useful contribution by either determining that the feature does work, or fixing it if it's busted. Probably wouldn't be a very complex fix, but I've never looked at that part of the code. If your total database will exceed the space available on a single filesystem on your platform, you will have to play some games with symbolic links in order to spread the table files across multiple filesystems. I don't know of any gotchas in doing that, but it's kind of a pain for the DB admin to have to do it by hand. regards, tom lane