Re: Fwd: Core dump with nested CREATE TEMP TABLE - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Fwd: Core dump with nested CREATE TEMP TABLE
Date
Msg-id 55E1D86D.7090106@BlueTreble.com
Whole thread Raw
In response to Re: Fwd: Core dump with nested CREATE TEMP TABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fwd: Core dump with nested CREATE TEMP TABLE  (Andres Freund <andres@anarazel.de>)
Re: Fwd: Core dump with nested CREATE TEMP TABLE  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 8/29/15 8:04 AM, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.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
atrelcache.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) +
1443at 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) +
128at 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) +
2095at 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
atexecQual.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
atexecMain.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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: to_json(NULL) should to return JSON null instead NULL
Next
From: Jim Nasby
Date:
Subject: Re: psql - better support pipe line