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: