Re: problem with large maintenance_work_mem settings and - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: problem with large maintenance_work_mem settings and
Date
Msg-id 4409C75A.2080802@kaltenbrunner.cc
Whole thread Raw
In response to Re: problem with large maintenance_work_mem settings and  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: problem with large maintenance_work_mem settings and
List pgsql-hackers
Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> 
>>>not that I think it is related to the problem at all. It looks like I'm
>>>hitting the MaxAllocSize Limit in src/include/utils/memutils.h.
> 
> 
>>just tried to increase this limit to 4GB (from the default 1GB) and this
>>seems to help a fair bit.
> 
> 
> s/help a fair bit/break a whole lot of stuff/
> 
> There are reasons for that limit, and you can't just arbitrarily
> rejigger it.

heh - sure this is just a testbox so it was worth a try and I don't care
for the data anyway ...

> 
> The sorting code probably needs a defense to keep it from trying to
> exceed MaxAllocSize for the SortObject array; AFAIR there is no such
> consideration there now, but it's easily added.  I'm not sure where your
> VACUUM failure is coming from though --- can you get a back trace from
> the errfinish call in that case?

like(with maintenance_work_mem set to 2000000):

(gdb) bt
#0  errfinish (dummy=0) at elog.c:310
#1  0x00000000005c6c93 in elog_finish (elevel=-4145840, fmt=0x84da50
"invalid memory alloc request size %lu")   at elog.c:931
#2  0x00000000005d96a0 in MemoryContextAlloc (context=0x8d9c58,
size=2047999998) at mcxt.c:505
#3  0x00000000004db947 in lazy_space_alloc (vacrelstats=0x8de5b0,
relblocks=6) at vacuumlazy.c:963
#4  0x00000000004dab33 in lazy_scan_heap (onerel=0x2ad69a589cc8,
vacrelstats=0x8de5b0, Irel=0x0, nindexes=0)   at vacuumlazy.c:240
#5  0x00000000004da9d1 in lazy_vacuum_rel (onerel=0x2ad69a589cc8,
vacstmt=0x8c0fd0) at vacuumlazy.c:157
#6  0x00000000004d7325 in vacuum_rel (relid=2589498568,
vacstmt=0x8c0fd0, expected_relkind=-27 'å')   at vacuum.c:1077
#7  0x00000000004d6990 in vacuum (vacstmt=0x8c0fd0, relids=0x0) at
vacuum.c:449
#8  0x000000000055e871 in PortalRunUtility (portal=0x8e0360,
query=0x8c0e00, dest=0x8c1050,   completionTag=0x7fffffc0c410 "") at pquery.c:987
#9  0x000000000055eb07 in PortalRunMulti (portal=0x8e0360,
dest=0x8c1050, altdest=0x8c1050,   completionTag=0x7fffffc0c410 "") at pquery.c:1054
#10 0x000000000055e28f in PortalRun (portal=0x8e0360,
count=9223372036854775807, dest=0x8c1050,   altdest=0x8c1050, completionTag=0x7fffffc0c410 "") at pquery.c:665
#11 0x000000000055a3a1 in exec_simple_query (query_string=0x8c0cf0
"VACUUM VERBOSE;") at postgres.c:1002
#12 0x000000000055cc2c in PostgresMain (argc=4, argv=0x84c078,
username=0x84c040 "postgres") at postgres.c:3217
#13 0x0000000000538a71 in BackendRun (port=0x86add0) at postmaster.c:2853
#14 0x0000000000538550 in BackendStartup (port=0x86add0) at
postmaster.c:2497
#15 0x0000000000536b4d in ServerLoop () at postmaster.c:1230
#16 0x0000000000535fcf in PostmasterMain (argc=3, argv=0x8493c0) at
postmaster.c:941
#17 0x00000000004fcaa5 in main (argc=3, argv=0x8493c0) at main.c:265


Stefan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Building Windows Server Extensions Using VC++ 2005
Next
From: Tom Lane
Date:
Subject: Not so happy with psql's new multiline behavior