From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | event triggers patch breaks with -DCLOBBER_CACHE_ALWAYS |
Date: | 2012-07-24 00:16:01 |
Message-ID: | 1343088961.18608.94.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Compiling 3a0e4d with -DCLOBBER_CACHE_ALWAYS causes initdb to segfault.
It looks like the tuple was allocated in the EventTriggerCacheContext,
and before the tuple was freed, another invalidation event came along
and wiped out that context.
It seems like the cleanest fix would be to explicitly allocate things in
the EventTriggerCacheContext, rather than switching the context.
However, it's not 100% clear to me that this is really a problem with
the event trigger patch itself. RelationBuildDesc is doing an allocation
in whatever the caller's context is, and freeing it. But in the
meantime, it does it's own catalog accesses and otherwise executes quite
a lot of code, and assumes that the memory context will stay intact the
entire time. Maybe that's a reasonable assumption, but as seen here, it
leaves room for error.
While looking at it, I observe that no context is passed to
hash_create(), and no hash_destroy() is called. Unless I'm missing
something, that's a leak in TopMemoryContext.
Regards,
Jeff Davis
#0 0x00000000004683a2 in extractRelOptions (tuple=0x11cd528,
tupdesc=0x7fc9e499b420, amoptions=0) at reloptions.c:778
#1 0x00000000008513f8 in RelationParseRelOptions
(relation=0x7fc9e495f490, tuple=0x11cd528) at relcache.c:388
#2 0x0000000000852695 in RelationBuildDesc (targetRelId=3466,
insertIt=1 '\001') at relcache.c:905
#3 0x0000000000854026 in RelationIdGetRelation (relationId=3466) at
relcache.c:1567
#4 0x000000000048a535 in relation_open (relationId=3466, lockmode=1) at
heapam.c:917
#5 0x000000000084d1bd in BuildEventTriggerCache () at evtcache.c:130
#6 0x000000000084d011 in EventCacheLookup (event=EVT_DDLCommandStart)
at evtcache.c:59
#7 0x00000000005bb1db in EventTriggerDDLCommandStart
(parsetree=0x11becd0) at event_trigger.c:594
#8 0x000000000075d102 in standard_ProcessUtility (parsetree=0x11becd0,
queryString=0x11bef98 "/*\n * PostgreSQL System Views\n *\n * Copyright
(c) 1996-2012, PostgreSQL Global Development Group\n *\n *
src/backend/catalog/system_views.sql\n */\n\nCREATE VIEW pg_roles AS\n
SELECT\n rolname,\n "..., params=0x0, dest=0xcdda60,
completionTag=0x7fff3476ea80 "", context=PROCESS_UTILITY_QUERY) at
utility.c:986
#9 0x000000000075bec9 in ProcessUtility (parsetree=0x11becd0,
queryString=0x11bef98 "/*\n * PostgreSQL System Views\n *\n * Copyright
(c) 1996-2012, PostgreSQL Global Development Group\n *\n *
src/backend/catalog/system_views.sql\n */\n\nCREATE VIEW pg_roles AS\n
SELECT\n rolname,\n "..., params=0x0, dest=0xcdda60,
completionTag=0x7fff3476ea80 "", context=PROCESS_UTILITY_QUERY) at
utility.c:338
#10 0x000000000075ae31 in PortalRunUtility (portal=0x11c8fe8,
utilityStmt=0x11becd0, isTopLevel=0 '\000', dest=0xcdda60,
completionTag=0x7fff3476ea80 "") at pquery.c:1186
#11 0x000000000075b018 in PortalRunMulti (portal=0x11c8fe8, isTopLevel=0
'\000', dest=0xcdda60, altdest=0xcdda60, completionTag=0x7fff3476ea80
"") at pquery.c:1318
#12 0x000000000075a54a in PortalRun (portal=0x11c8fe8,
count=9223372036854775807, isTopLevel=0 '\000', dest=0xcdda60,
altdest=0xcdda60, completionTag=0x7fff3476ea80 "") at pquery.c:815
#13 0x00000000007545b2 in exec_simple_query (query_string=0x11bef98 "/*
\n * PostgreSQL System Views\n *\n * Copyright (c) 1996-2012, PostgreSQL
Global Development Group\n *\n * src/backend/catalog/system_views.sql\n
*/\n\nCREATE VIEW pg_roles AS\n SELECT\n rolname,\n "...) at
postgres.c:1053
#14 0x00000000007587fe in PostgresMain (argc=10, argv=0x10f29b0,
username=0x10f6eb0 "jdavis") at postgres.c:3972
#15 0x00000000006630fa in main (argc=10, argv=0x10f29b0) at main.c:195
From | Date | Subject | |
---|---|---|---|
Next Message | pilum.70 | 2012-07-24 12:45:56 | BUG #6751: usage flaws in pg_restore |
Previous Message | Tom Lane | 2012-07-23 18:43:34 | Re: BUG #6748: sequence value may be conflict in some cases |