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: 2008-02-10 01:44:17
Message-ID: 20080210014417.GB27757@louise.pinerecords.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> > Trying to run "vacuum full analyze" on a ~200MB UTF8 database fails with:
> >
> > fs=> vacuum full analyze;
> > WARNING: skipping "pg_authid" --- only table or database owner can vacuum it
> > WARNING: skipping "pg_database" --- only table or database owner can vacuum it
> > WARNING: skipping "pg_shdepend" --- only table or database owner can vacuum it
> > WARNING: skipping "pg_shdescription" --- only table or database owner can vacuum it
> > WARNING: skipping "pg_auth_members" --- only table or database owner can vacuum it
> > ERROR: invalid memory alloc request size 4294965504
>
> Hmm, please see if you can get a stack trace from that (set the
> breakpoint at errfinish()). You might want to use vacuum verbose
> first so that you can figure out which individual table is causing it.

Ok, I recompiled CVS head with --enable-debug and with --enable-cassert
and hit the following assert on "vacuum full verbose analyze":

[snip]
INFO: vacuuming "pg_catalog.pg_class"
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Assert (from the log):
TRAP: FailedAssertion("!((BlockNumber) fraged_pages->num_pages >= empty_end_pages)", File: "vacuum.c", Line: 1737)

Backtrace:
#0 0xb7b54797 in raise () from /lib/libc.so.6
#1 0xb7b560b8 in abort () from /lib/libc.so.6
#2 0x08292713 in ExceptionalCondition (
conditionName=0x8335d58 "!((BlockNumber) fraged_pages->num_pages >= empty_end_pages)", errorType=0x82bdca2 "FailedAssertion", fileName=0x82bfbfa "vacuum.c",
lineNumber=1737) at assert.c:57
#3 0x0815b9d4 in full_vacuum_rel (onerel=0x841ad4c, vacstmt=0x844a4d0)
at vacuum.c:1737
#4 0x0815ec35 in vacuum_rel (relid=<value optimized out>, vacstmt=0x844a4d0,
expected_relkind=114 'r') at vacuum.c:1117
#5 0x0815ee19 in vacuum (vacstmt=0x6, relids=0x0, bstrategy=0x0,
isTopLevel=<value optimized out>) at vacuum.c:423
#6 0x081fcec5 in PortalRunUtility (portal=0x8474acc, utilityStmt=0x844a4d0,
isTopLevel=0 '\0', dest=0x844a52c, completionTag=0xbfd41dba "") at pquery.c:1173
#7 0x081fdc97 in PortalRunMulti (portal=0x8474acc,
isTopLevel=<value optimized out>, dest=0x844a52c, altdest=0x844a52c,
completionTag=0xbfd41dba "") at pquery.c:1268
#8 0x081fe3f3 in PortalRun (portal=0x8474acc, count=2147483647,
isTopLevel=6 '\006', dest=0x844a52c, altdest=0x844a52c,
completionTag=0xbfd41dba "") at pquery.c:813
#9 0x081f9bce in exec_simple_query (
query_string=0x8449c8c "vacuum full verbose analyze;") at postgres.c:963
#10 0x081fa951 in PostgresMain (argc=4, argv=0x83d63e4, username=0x83d63bc "kala")
at postgres.c:3530
#11 0x081cc83a in ServerLoop () at postmaster.c:3207
#12 0x081cd32d in PostmasterMain (argc=4, argv=0x83d31c0) at postmaster.c:1029
#13 0x0818717e in main (argc=4, argv=0x83d31c0) at main.c:188

Recompiled CVS head again, this time with --enable-debug but without
--enable-cassert. On "vacuum full verbose analyze," I hit the following:

[snip]
INFO: vacuuming "pg_catalog.pg_attribute"
INFO: "pg_attribute": found 23891 removable, 3520 nonremovable row versions in 1301 pages
DETAIL: 0 dead row versions cannot be removed yet.
Nonremovable row versions range from 128 to 128 bytes long.
There were 34 unused item pointers.
Total free space (including removable row versions) is 9679844 bytes.
1243 pages are or will become empty, including 1243 at the end of the table.
4294967291 pages containing 0 free bytes are potential move destinations.
CPU 0.03s/0.01u sec elapsed 1.72 sec.
INFO: index "pg_attribute_relid_attnam_index" now contains 3520 row versions in 1242 pages
DETAIL: 108686 index row versions were removed.
1182 index pages have been deleted, 1182 are currently reusable.
CPU 0.02s/0.05u sec elapsed 0.31 sec.
INFO: index "pg_attribute_relid_attnum_index" now contains 3520 row versions in 309 pages
DETAIL: 108686 index row versions were removed.
296 index pages have been deleted, 296 are currently reusable.
CPU 0.02s/0.04u sec elapsed 0.12 sec.
INFO: "pg_attribute": truncated 1301 to 58 pages
ERROR: invalid memory alloc request size 4294967256

Backtrace:
#0 errfinish (dummy=0) at elog.c:307
#1 0x082629a4 in elog_finish (elevel=20,
fmt=0x832dd0c "invalid memory alloc request size %lu") at elog.c:951
#2 0x082778fc in MemoryContextAlloc (context=0x8388e58, size=4294967256)
at mcxt.c:510
#3 0x08141801 in full_vacuum_rel (onerel=0x83bcaf0, vacstmt=0x83f84c0)
at vacuum.c:3463
#4 0x08142229 in vacuum_rel (relid=<value optimized out>, vacstmt=0x83f84c0,
expected_relkind=114 'r') at vacuum.c:1117
#5 0x081423ed in vacuum (vacstmt=0x7, relids=0x0, bstrategy=0x0,
isTopLevel=<value optimized out>) at vacuum.c:423
#6 0x081cf70d in PortalRunUtility (portal=0x8422ac8, utilityStmt=0x83f84c0,
isTopLevel=88 'X', dest=0x83f8510, completionTag=0xbfac7b2a "") at pquery.c:1173
#7 0x081d0321 in PortalRunMulti (portal=0x8422ac8,
isTopLevel=<value optimized out>, dest=0x83f8510, altdest=0x83f8510,
completionTag=0xbfac7b2a "") at pquery.c:1268
#8 0x081d0a47 in PortalRun (portal=0x8422ac8, count=2147483647, isTopLevel=7 '\a',
dest=0x83f8510, altdest=0x83f8510, completionTag=0xbfac7b2a "") at pquery.c:813
#9 0x081cc4ba in exec_simple_query (
query_string=0x83f7c88 "vacuum full verbose analyze;") at postgres.c:963
#10 0x081cd23d in PostgresMain (argc=4, argv=0x83843b0, username=0x8384390 "kala")
at postgres.c:3530
#11 0x081a6785 in ServerLoop () at postmaster.c:3207
#12 0x081a722d in PostmasterMain (argc=4, argv=0x83811c0) at postmaster.c:1029
#13 0x08166b02 in main (argc=4, argv=0x83811c0) at main.c:188

Hope this helps. Please let me know if you need additional info.

Best regards,
--
Tomas Szepe <szepe(at)pinerecords(dot)com>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jorge Campins 2008-02-10 02:20:00 Re: BUG #3948: date/time functions returning wrong value
Previous Message Tom Lane 2008-02-10 00:25:45 Re: BUG #3948: date/time functions returning wrong value