Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: 8.3.0: vacuum full analyze: "invalid memory alloc request size"


  • 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: Sun, 10 Feb 2008 19:56:45 +0100
  • Message-id: <20080210185645(dot)GA1560(at)louise(dot)pinerecords(dot)com>

> 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>



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group