>
> *CC mailing* : I got the bounced mail as in attachment from you when I
> CCed to "pgsql-admin@postgresql.org" So, I am not doing so.
>
Like the message says, you should contact the powers that be to figure out
what happened. Please always email the mailing list, as I am *not* your
personal help
>
> I had a file with name "dump_live" which contains all the dump using
> "pg_dumpall > dump_live". Now, I need to restore it to another schema
> "schema2". How can I restore the data from that file to specified empty
> schema2. (This schema is created with out any objects). Pls advice me how to
>
[EMAIL PROTECTED] writes:
>> Hmmm ... in 7.4 16408 is pg_statistic, which fortunately for you is all
>> easily-regenerated data. I'd try "DELETE FROM pg_statistic".
> Deleting from pg_statistic produced error: xlog flush request 58/A0AFB340
> is not satisfied --- flushed only to 5/B2004628
> CONT
Michael Goldner <[EMAIL PROTECTED]> writes:
> On 11/5/07 12:19 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>> It might be interesting to look at stats such as
>> select sum(length(data)) from pg_largeobject;
>> to confirm that your 100GB estimate for the data payload is accurate.
> That select retur
[EMAIL PROTECTED] writes:
> I am running PGSQL 7.4 on a Solaris 9 system.
7.4.what exactly?
> I am trying to upgrade to
> 8.2.5. Both 7.4 and 8.2.5 are on the same server. When I try to use 8.2.5
> pg_dumpall to dump the 7.4 databse I receive the following error:
> pg_dumpall: query failed: ERROR
On Mon, Nov 05, 2007 at 08:07:04AM +0100, Peter Eisentraut wrote:
> Am Samstag, 3. November 2007 schrieb Tom Lane:
> > > That also seems to have the positive effect of getting libpq.so to find
> > > the shared objects that it depends on. So is the fact that I need to
> > > edit src/Makefile.global
I am running PGSQL 7.4 on a Solaris 9 system. I am trying to upgrade to
8.2.5. Both 7.4 and 8.2.5 are on the same server. When I try to use 8.2.5
pg_dumpall to dump the 7.4 databse I receive the following error:
pg_dumpall: query failed: ERROR: xlog flush request 58/A0AFB0C0 is not
satisfied --- f
On 11/5/07 12:19 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Michael Goldner <[EMAIL PROTECTED]> writes:
>> The pg_largeobject table, however, seems a bit odd:
>
>> INFO: vacuuming "pg_catalog.pg_largeobject"
>> INFO: index "pg_largeobject_loid_pn_index" now contains 105110204 row
>> version
