From: | Tomas Szepe <szepe(at)pinerecords(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: 8.3.0: vacuum full analyze: "invalid memory alloc request size" |
Date: | 2008-02-10 18:56:45 |
Message-ID: | 20080210185645.GA1560@louise.pinerecords.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> After poking around in the code a bit, I found a way to reproduce the
> assert failure:
[snip]
Great!
> Another issue is that while I can create a page with
> MaxHeapTuplesPerPage dead tuples easily enough in testing, it's not
> clear how you managed to get into that state in the system catalogs.
> Neither pg_class nor pg_attribute can have minimal-length tuples.
> Are you doing anything that would involve lots of updates in these
> catalogs --- maybe repeatedly renaming a column, or something like that?
Hmm, I typically use a pair of
"ALTER TABLE table DISABLE TRIGGER USER;"/
"ALTER TABLE table ENABLE TRIGGER USER;"
per almost every relation when loading a dump, other than that there's
only the initial db creation code (lots of plpgsql triggers and a couple
immutable functions) and then using temp tables for complicated queries.
Thanks again for looking into this,
--
Tomas Szepe <szepe(at)pinerecords(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-02-10 19:14:31 | Re: 8.3.0: vacuum full analyze: "invalid memory alloc request size" |
Previous Message | vha | 2008-02-10 18:55:18 | BUG #3951: SELECT ... WHERE Param = ? does not work if Param is of type bytea |