From: | "Tim Perdue" <perdue(at)raccoon(dot)com> |
---|---|
To: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Problems with >2GB tables on Linux 2.0 |
Date: | 1999-03-17 13:08:52 |
Message-ID: | 009a01be7077$4e665120$0b8c5aa5@timnt.weather.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I am still not able to pg_dump my data after recovering from this disaster.
My files are now segmented at 1GB, vacuuming is fine, but pg_dump has a
problem "locating the template1 database".
I sure hope someone can help me come up with a way to safely backup this
data. Someone sent me a patch for the Linux Kernel that will allow it to
handle files > 2GB, but that won't help me with my backup problems.
Thanks,
Tim Perdue
geocrawler.com
-----Original Message-----
From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>
Cc: t-ishii(at)sra(dot)co(dot)jp <t-ishii(at)sra(dot)co(dot)jp>; Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>;
pgsql-hackers(at)postgreSQL(dot)org <pgsql-hackers(at)postgreSQL(dot)org>
Date: Tuesday, March 16, 1999 10:45 PM
Subject: Re: [HACKERS] Problems with >2GB tables on Linux 2.0
>>Just a question. Does your patch let vacuum handle segmented tables?
>>--
>>Tatsuo Ishii
>
>>It simply reduces the size of each segment from 2Gb to 1Gb. The problem
>>was that some OS's (Linux in my case) don't like files exactly 2Gb in
>>size. I don't know how vacuum interacts with the storage manager, but in
>>theory it should be transparent.
>
>Ok. So we still have following problem:
>
>test=> vacuum smallcat;
>NOTICE: Can't truncate multi-segments relation smallcat
>VACUUM
>
>Maybe this should be added to TODO if it's not already there.
>--
>Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 1999-03-17 13:47:17 | Re: [HACKERS] Problems with >2GB tables on Linux 2.0 |
Previous Message | Tatsuo Ishii | 1999-03-17 10:10:13 | Re: [HACKERS] Re: Developers Globe (FINAL) |