Re: 8.3.0: vacuum full analyze: "invalid memory alloc request size"
От | Tomas Szepe |
---|---|
Тема | Re: 8.3.0: vacuum full analyze: "invalid memory alloc request size" |
Дата | |
Msg-id | 20080210185645.GA1560@louise.pinerecords.com обсуждение исходный текст |
Ответ на | Re: 8.3.0: vacuum full analyze: "invalid memory alloc request size" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 8.3.0: vacuum full analyze: "invalid memory alloc request size"
|
Список | 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@pinerecords.com>
В списке pgsql-bugs по дате отправления: