Re: Repeated crashes in GENERATED ... AS IDENTITY tests
От | Alvaro Herrera |
---|---|
Тема | Re: Repeated crashes in GENERATED ... AS IDENTITY tests |
Дата | |
Msg-id | 20180419204946.5ujino6w4dy7biuc@alvherre.pgsql обсуждение исходный текст |
Ответ на | Repeated crashes in GENERATED ... AS IDENTITY tests (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Repeated crashes in GENERATED ... AS IDENTITY tests
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Repeated crashes in GENERATED ... AS IDENTITY tests (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
Tom Lane wrote: > The test case that's failing, in identity.sql, has been there since > early February; the lack of any crashes till more recently suggests > that something committed in mid-to-late March broke it. > > I have no idea what's going on there, but I think this is clearly > something we need to consider an open item for PG11. I'll put it > on the list. Grumble. Of the machines you listed, conchuela has gdb installed, which gives us a nice backtrace of the crash, pasted below, which seems to blame event triggers. Of the tests in the same parallel group as identity, the test fast_default seems to be the only one with an event trigger and was added on March 28th by 16828d5c0273. That combination seems to explain why the crashes appeared late ... I can't look further into this now -- maybe next week if nobody has beaten me into it. My guess is that the identity stuff is not setting state like event triggers expect. https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2018-04-03%2010%3A00%3A00 ================== stack trace: pgsql.build/src/test/regress/tmp_check/data/postgres.core ================== [New <main task>] Core was generated by `postgres'. Program terminated with signal 11, Segmentation fault. #0 EventTriggerTableRewrite (parsetree=parsetree@entry=0x80a852670, tableOid=49861, reason=2) at event_trigger.c:974 974 currentEventTriggerState->table_rewrite_oid = tableOid; #0 EventTriggerTableRewrite (parsetree=parsetree@entry=0x80a852670, tableOid=49861, reason=2) at event_trigger.c:974 #1 0x0000000000601bfc in ATRewriteTables (lockmode=8, wqueue=0x7fffffffe3d8, parsetree=0x80a852670) at tablecmds.c:4326 #2 ATController (parsetree=parsetree@entry=0x80a852670, rel=<optimized out>, cmds=<optimized out>, recurse=<optimized out>,lockmode=lockmode@entry=8) at tablecmds.c:3536 #3 0x00000000006021af in AlterTable (relid=relid@entry=49861, lockmode=lockmode@entry=8, stmt=stmt@entry=0x80a852670) attablecmds.c:3206 #4 0x000000000077df9f in ProcessUtilitySlow (pstate=pstate@entry=0x80a852118, pstmt=pstmt@entry=0x801647110, queryString=queryString@entry=0x801646118"ALTER TABLE itest13 ADD COLUMN b int GENERATED BY DEFAULT AS IDENTITY;", context=context@entry=PROCESS_UTILITY_TOPLEVEL,params=params@entry=0x0, queryEnv=queryEnv@entry=0x0, completionTag=0x7fffffffe830"", dest=0x801647400) at utility.c:1116 #5 0x000000000077c632 in standard_ProcessUtility (pstmt=0x801647110, queryString=0x801646118 "ALTER TABLE itest13 ADD COLUMNb int GENERATED BY DEFAULT AS IDENTITY;", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, dest=0x801647400,completionTag=0x7fffffffe830 "") at utility.c:919 #6 0x0000000000779e05 in PortalRunUtility (portal=0x80a60c118, pstmt=0x801647110, isTopLevel=<optimized out>, setHoldSnapshot=<optimizedout>, dest=0x801647400, completionTag=0x7fffffffe830 "") at pquery.c:1183 #7 0x000000000077a925 in PortalRunMulti (portal=portal@entry=0x80a60c118, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false,dest=dest@entry=0x801647400, altdest=altdest@entry=0x801647400, completionTag=completionTag@entry=0x7fffffffe830"") at pquery.c:1336 #8 0x000000000077b5be in PortalRun (portal=portal@entry=0x80a60c118, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true,run_once=run_once@entry=true, dest=dest@entry=0x801647400, altdest=altdest@entry=0x801647400,completionTag=0x7fffffffe830 "") at pquery.c:804 #9 0x00000000007771e5 in exec_simple_query (query_string=0x801646118 "ALTER TABLE itest13 ADD COLUMN b int GENERATED BYDEFAULT AS IDENTITY;") at postgres.c:1121 #10 0x000000000077869b in PostgresMain (argc=<optimized out>, argv=argv@entry=0x8012f03e8, dbname=0x8012f0190 "regression",username=<optimized out>) at postgres.c:4149 #11 0x0000000000480398 in BackendRun (port=0x8016c0280) at postmaster.c:4409 #12 BackendStartup (port=0x8016c0280) at postmaster.c:4081 #13 ServerLoop () at postmaster.c:1754 #14 0x0000000000701009 in PostmasterMain (argc=argc@entry=8, argv=argv@entry=0x7ffffffff5d0) at postmaster.c:1362 #15 0x0000000000481978 in main (argc=8, argv=0x7ffffffff5d0) at main.c:228 -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Alvaro HerreraДата:
Сообщение: Re: reloption to prevent VACUUM from truncating empty pages at theend of relation