Re: vacuumdb: ERROR: invalid memory alloc request size 4294967292

Hi all,

vacuumdb (and autovacuum) fails for two of nine databases with the error
message:

vacuumdb -v -e -z pgcmisnlt1
VACUUM VERBOSE ANALYZE;
INFO: vacuuming "information_schema.sql_features"
vacuumdb: vacuuming of database "pgcmisnlt1" failed: ERROR: invalid
memory alloc request size 4294967292

From the log:
LOG: 00000: autovacuum: processing database "pgcmisnls1"
LOCATION: AutoVacMain, autovacuum.c:408
ERROR: XX000: invalid memory alloc request size 4294967292
LOCATION: MemoryContextAlloc, mcxt.c:505

It does not matter if the entire database is vacuum-ed or just a single
table. The other database is identical to this one, but build from
scratch, so the problem is reproducable. The database never crashed or
shutdown uncleanly.

Any thoughts?

Thanks,

Harco

Below is all the info I could come up with

Postgres version:
PostgreSQL 8.1.3 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC)
3.3.3 (SuSE Linux)

(gdb) b mcxt.c:505
Breakpoint 1 at 0x5e4f38: file mcxt.c, line 505.
(gdb) cont
..
(gdb) bt
#0 MemoryContextAlloc (context=0x8b3a10, size=4294967292) at mcxt.c:505
#1 0x00000000004e06f9 in lazy_vacuum_rel (onerel=0x2a955ecbd8,
vacstmt=0x8bf390) at vacuumlazy.c:963
#2 0x00000000004deade in vacuum_rel (relid=<value optimized out>,
vacstmt=0x8bf390, expected_relkind=114 'r') at vacuum.c:1077
#3 0x00000000004df85e in vacuum (vacstmt=0x8bf390, relids=0x8cd920)
at vacuum.c:449
#4 0x0000000000564207 in PortalRunUtility (portal=0x8cb100, query=0x8bf1c0,
dest=0x8bf410, completionTag=0x7fbfffdbc0 "") at pquery.c:987
#5 0x000000000056595d in PortalRun (portal=0x8cb100,
count=9223372036854775807, dest=0x8bf410, altdest=0x8bf410,
completionTag=0x7fbfffdbc0 "") at pquery.c:1054
#6 0x00000000005611f6 in exec_simple_query (
query_string=0x8bf0b0 "VACUUM VERBOSE ANALYZE;") at postgres.c:1002
#7 0x0000000000562ccd in PostgresMain (argc=4, argv=0x8437f0,
username=0x8437b0 "postgres") at postgres.c:3217
#8 0x000000000053d07a in ServerLoop () at postmaster.c:2851
#9 0x000000000053dca4 in PostmasterMain (argc=1, argv=0x83ef70)
at postmaster.c:941
#10 0x0000000000503197 in main (argc=1, argv=0x83ef70) at main.c:265

(gdb) print *context
$3 = {type = T_AllocSetContext, methods = 0x7a2620, parent = 0x8425f0,
firstchild = 0x0, nextchild = 0x8b2390,
name = 0x8b3ac0 "TopTransactionContext"}

(gdb) up
#1 0x00000000004e06f9 in lazy_vacuum_rel (onerel=0x2a955ecbd8,
vacstmt=0x8bf390) at vacuumlazy.c:963
963 vacrelstats->dead_tuples = (ItemPointer)
(gdb) print *onerel
$4 = {rd_node = {spcNode = 1663, dbNode = 3975706, relNode = 10723},
rd_smgr = 0x8c3310, rd_targblock = 4294967295, rd_refcnt = 1,
rd_istemp = 0 '\0', rd_isnailed = 0 '\0', rd_isvalid = 1 '\001',
rd_indexvalid = 1 '\001', rd_createSubid = 0, rd_rel = 0x2a955ecce8,
rd_att = 0x2a955c8950, rd_id = 10723, rd_indexlist = 0x0, rd_oidindex = 0,
rd_lockInfo = {lockRelId = {relId = 10723, dbId = 3975706}}, rd_rules
= 0x0,
rd_rulescxt = 0x0, trigdesc = 0x0, rd_index = 0x0, rd_indextuple = 0x0,
rd_indclass = 0x0, rd_am = 0x0, rd_indexcxt = 0x0, rd_aminfo = 0x0,
rd_operator = 0x0, rd_support = 0x0, rd_supportinfo = 0x0,
rd_indexprs = 0x0, rd_indpred = 0x0, pgstat_info = {tabentry = 0x0}}

Harco de Hilster <Harco(dot)de(dot)Hilster(at)ATConsultancy(dot)nl> writes:
> (gdb) bt
> #0 MemoryContextAlloc (context=0x8b3a10, size=4294967292) at mcxt.c:505
> #1 0x00000000004e06f9 in lazy_vacuum_rel (onerel=0x2a955ecbd8,
> vacstmt=0x8bf390) at vacuumlazy.c:963

What do you have maintenance_work_mem set to? If it's larger than 1Gb
you need to back it off, or apply this patch:
http://archives.postgresql.org/pgsql-committers/2006-03/msg00094.php

regards, tom lane

That did the trick. Thanks.

Kind regards,

Harco

Tom Lane wrote:

>Harco de Hilster <Harco(dot)de(dot)Hilster(at)ATConsultancy(dot)nl> writes:
>
>
>>(gdb) bt
>>#0 MemoryContextAlloc (context=0x8b3a10, size=4294967292) at mcxt.c:505
>>#1 0x00000000004e06f9 in lazy_vacuum_rel (onerel=0x2a955ecbd8,
>> vacstmt=0x8bf390) at vacuumlazy.c:963
>>
>>
>
>What do you have maintenance_work_mem set to? If it's larger than 1Gb
>you need to back it off, or apply this patch:
>http://archives.postgresql.org/pgsql-committers/2006-03/msg00094.php
>
> regards, tom lane
>
>
>