Re: Fwd: Core dump with nested CREATE TEMP TABLE

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fwd: Core dump with nested CREATE TEMP TABLE
Date: 2015-08-29 16:06:05
Message-ID: 55E1D86D.7090106@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/29/15 8:04 AM, Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> Ah, OK, you meant this file... Yes I was able to receive it as well in your
>> original email. I'll try to investigate further later, but Tom may beat me
>> first. He usually does.
>
> Jim had indicated the bug wasn't reproducible on the strength of that
> info, so I was waiting for him to provide a more reproducible case.

It was reproducible, just not very self contained. [1] is a bit better,
but it still involves pgTap as well as test_factory.

Steps to reproduce:
Download https://github.com/BlueTreble/test_factory/archive/crash.zip
Unzip, cd into directory
pgxn install pgtap (or just make test)
make install if you didn't do make test
psql -f crash.sql

Stack trace below. Relevant assert:

1967 * As per notes above, a rel to be rebuilt MUST have refcnt >
0; while of
1968 * course it would be a bad idea to blow away one with nonzero
refcnt.
1969 */
-> 1970 Assert(rebuild ?
1971 !RelationHasReferenceCountZero(relation) :
1972 RelationHasReferenceCountZero(relation));

Relevant bits of relation:
> │ ◆─(Relation) relation = 0x00000001165832a8 ││ │
> │ ├─◆─(RelFileNode) rd_node ││ │
> │ ├─◆─(SMgrRelationData *) rd_smgr = 0x0000000000000000 ││ │
> │ ├─(int) rd_refcnt = 1 ││ │
> │ ├─(BackendId) rd_backend = 2 ││ │
> │ ├─(bool) rd_islocaltemp = '\x01' ││ │
> │ ├─(bool) rd_isnailed = '\0' ││ │
> │ ├─(bool) rd_isvalid = '\x01' ││ │
> │ ├─(char) rd_indexvalid = '\0' ││ │
> │ ├─(SubTransactionId) rd_createSubid = 16 ││ │
> │ ├─(SubTransactionId) rd_newRelfilenodeSubid = 0 ││ │
> │ ├─◆─(Form_pg_class) rd_rel = 0x00000001165838d8 ││ │
> │ │ ├─◆─(NameData) relname ││ │
> │ │ │ └─◆─(char [64]) data "invoice_0000000003"

rebuild is 0.

[1]https://github.com/BlueTreble/test_factory/blob/crash/crash.sql

> (lldb) bt
> * thread #1: tid = 0x3b03a0, 0x00007fff92a5a866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
> * frame #0: 0x00007fff92a5a866 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x00007fff9001b35c libsystem_pthread.dylib`pthread_kill + 92
> frame #2: 0x00007fff8cf89b1a libsystem_c.dylib`abort + 125
> frame #3: 0x000000010cdb4039 postgres`ExceptionalCondition(conditionName=0x000000010cf59cfd, errorType=0x000000010cec392d, fileName=0x000000010cf59045, lineNumber=1972) + 137 at assert.c:54
> frame #4: 0x000000010cd9b332 postgres`RelationClearRelation(relation=0x0000000116594cd8, rebuild='\0') + 162 at relcache.c:1970
> frame #5: 0x000000010cd9cc0f postgres`AtEOSubXact_cleanup(relation=0x0000000116594cd8, isCommit='\0', mySubid=15, parentSubid=14) + 79 at relcache.c:2665
> frame #6: 0x000000010cd9cb92 postgres`AtEOSubXact_RelationCache(isCommit='\0', mySubid=15, parentSubid=14) + 242 at relcache.c:2633
> frame #7: 0x000000010c9b6e88 postgres`AbortSubTransaction + 440 at xact.c:4373
> frame #8: 0x000000010c9b8ef2 postgres`RollbackAndReleaseCurrentSubTransaction + 178 at xact.c:3948
> frame #9: 0x0000000116295c93 plpgsql.so`exec_stmt_block(estate=0x00007fff532bfa50, block=0x00007fa3f56ab600) + 1443 at pl_exec.c:1214
> frame #10: 0x0000000116294625 plpgsql.so`plpgsql_exec_function(func=0x00007fa3f5369c10, fcinfo=0x00007fa3f5634160, simple_eval_estate=0x0000000000000000) + 837 at pl_exec.c:344
> frame #11: 0x000000011628dbb6 plpgsql.so`plpgsql_call_handler(fcinfo=0x00007fa3f5634160) + 470 at pl_handler.c:243
> frame #12: 0x000000010caf2471 postgres`ExecMakeFunctionResultNoSets(fcache=0x00007fa3f56340f0, econtext=<unavailable>, isNull=0x00007fff532bfd5b, isDone=<unavailable>) + 209 at execQual.c:2026
> frame #13: 0x0000000116299772 plpgsql.so`exec_eval_simple_expr(estate=0x00007fff532c0090, expr=0x00007fa3f53a1e60, result=0x00007fff532bfd10, isNull=0x00007fff532bfd5b, rettype=0x00007fff532bfd5c) + 562 at pl_exec.c:5203
> frame #14: 0x000000011629911d plpgsql.so`exec_eval_expr(estate=0x00007fff532c0090, expr=0x00007fa3f53a1e60, isNull=0x00007fff532bfd5b, rettype=0x00007fff532bfd5c) + 93 at pl_exec.c:4790
> frame #15: 0x000000011629ac70 plpgsql.so`exec_assign_expr(estate=0x00007fff532c0090, target=0x00007fa3f541c100, expr=0x00007fa3f53a1e60) + 48 at pl_exec.c:3992
> frame #16: 0x000000011629b300 plpgsql.so`exec_stmt_assign(estate=0x00007fff532c0090, stmt=0x00007fa3f53a1f50) + 128 at pl_exec.c:1511
> frame #17: 0x000000011629af6c plpgsql.so`exec_stmt(estate=0x00007fff532c0090, stmt=0x00007fa3f53a1f50) + 252 at pl_exec.c:1399
> frame #18: 0x000000011629ad1e plpgsql.so`exec_stmts(estate=0x00007fff532c0090, stmts=0x00007fa3f53a1bd0) + 126 at pl_exec.c:1362
> frame #19: 0x0000000116295f1f plpgsql.so`exec_stmt_block(estate=0x00007fff532c0090, block=0x00007fa3f53a21d0) + 2095 at pl_exec.c:1300
> frame #20: 0x0000000116294625 plpgsql.so`plpgsql_exec_function(func=0x00007fa3f52b1a30, fcinfo=0x00007fa3f53f9500, simple_eval_estate=0x0000000000000000) + 837 at pl_exec.c:344
> frame #21: 0x000000011628dbb6 plpgsql.so`plpgsql_call_handler(fcinfo=0x00007fa3f53f9500) + 470 at pl_handler.c:243
> frame #22: 0x000000010caf2471 postgres`ExecMakeFunctionResultNoSets(fcache=0x00007fa3f53f9490, econtext=<unavailable>, isNull=0x00007fa3f53f9f98, isDone=<unavailable>) + 209 at execQual.c:2026
> frame #23: 0x000000010caf1a4d postgres`ExecProject [inlined] ExecTargetList(targetlist=<unavailable>, econtext=<unavailable>, values=<unavailable>, isnull=<unavailable>, itemIsDone=<unavailable>, isDone=<unavailable>) + 90 at execQual.c:5307
> frame #24: 0x000000010caf19f3 postgres`ExecProject(projInfo=<unavailable>, isDone=0x00007fff532c033c) + 323 at execQual.c:5522
> frame #25: 0x000000010cb07233 postgres`ExecResult(node=0x00007fa3f53f9150) + 179 at nodeResult.c:155
> frame #26: 0x000000010caeae1c postgres`ExecProcNode(node=0x00007fa3f53f9150) + 92 at execProcnode.c:373
> frame #27: 0x000000010cae6836 postgres`ExecutePlan(estate=0x00007fa3f53f9038, planstate=0x00007fa3f53f9150, operation=CMD_SELECT, sendTuples='\x01', numberTuples=0, direction=ForwardScanDirection, dest=0x00007fa3f53cd740) + 118 at execMain.c:1490
> frame #28: 0x000000010cae675b postgres`standard_ExecutorRun(queryDesc=0x00007fa3f54f3638, direction=ForwardScanDirection, count=0) + 523 at execMain.c:319
> frame #29: 0x000000010cae653d postgres`ExecutorRun(queryDesc=0x00007fa3f54f3638, direction=ForwardScanDirection, count=0) + 77 at execMain.c:267
> frame #30: 0x000000010cc2a2b7 postgres`PortalRunSelect(portal=0x00007fa3f3012638, forward=<unavailable>, count=0, dest=<unavailable>) + 263 at pquery.c:946
> frame #31: 0x000000010cc29dd5 postgres`PortalRun(portal=0x00007fa3f3012638, count=9223372036854775807, isTopLevel=<unavailable>, dest=0x00007fa3f53cd740, altdest=<unavailable>, completionTag=0x00007fff532c06d0) + 469 at pquery.c:790
> frame #32: 0x000000010cc25b86 postgres`exec_simple_query(query_string=0x00007fa3f300e638) + 1302 at postgres.c:1072
> frame #33: 0x000000010cc24def postgres`PostgresMain(argc=1, argv=0x00007fa3f401c5f0, dbname=0x00007fa3f401c450, username=0x00007fa3f30031f8) + 2895 at postgres.c:4074
> frame #34: 0x000000010cb9da48 postgres`PostmasterMain [inlined] BackendRun + 8024 at postmaster.c:4155
> frame #35: 0x000000010cb9da22 postgres`PostmasterMain [inlined] BackendStartup at postmaster.c:3829
> frame #36: 0x000000010cb9da22 postgres`PostmasterMain [inlined] ServerLoop at postmaster.c:1597
> frame #37: 0x000000010cb9da22 postgres`PostmasterMain(argc=<unavailable>, argv=<unavailable>) + 7986 at postmaster.c:1244
> frame #38: 0x000000010cb218cd postgres`main(argc=<unavailable>, argv=<unavailable>) + 1325 at main.c:228
> frame #39: 0x00007fff8e9a35fd libdyld.dylib`start + 1
> (lldb)

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-08-29 16:07:52 Re: psql - better support pipe line
Previous Message Pavel Stehule 2015-08-29 16:02:15 Re: to_json(NULL) should to return JSON null instead NULL