Re: [BUGS] pg_logical_slot_peek_changes crashes postgres when calledfrom inside pl/pgsql

On Thu, Oct 5, 2017 at 5:59 AM, Ben Chobot <bench@silentmedia.com> wrote:
> I'm probably doing something dumb, but even something dumb at this high
> level probably shouldn't result in a crash. I've tried with multiple
> decoders and get the same result.

Yes, I can reproduce the problem easily. With assertions enabled, this
blows up differently:   frame #3: 0x000000010278ef20
postgres`ExceptionalCondition(conditionName="!(_SPI_current->tuptable
== ((void*)0))", errorType="FailedAssertion", fileName="spi.c",
lineNumber=297) + 128 at assert.c:54   frame #4: 0x000000010240c88b
postgres`AtEOSubXact_SPI(isCommit='\0', mySubid=2) + 811 at spi.c:297   frame #5: 0x00000001021fb4d9
postgres`AbortSubTransaction+ 553 at
 
xact.c:4813   frame #6: 0x00000001021fb8d2 postgres`AbortCurrentTransaction +
306 at xact.c:3113   frame #7: 0x0000000102544315
postgres`ReorderBufferCommit(rb=0x00007fba41845a40, xid=556,
commit_lsn=23043200, end_lsn=23043608, commit_time=560497405054853,
origin_id=0, origin_lsn=0) + 2501 at reorderbuffer.c:1624   frame #8: 0x0000000102537311
postgres`DecodeCommit(ctx=0x00007fba41835840, buf=0x00007fff5daf2168,
parsed=0x00007fff5daf20b0, xid=556) + 545 at decode.c:611   frame #9: 0x000000010253682c
postgres`DecodeXactOp(ctx=0x00007fba41835840, buf=0x00007fff5daf2168)
+ 364 at decode.c:241   frame #10: 0x00000001025363fe
postgres`LogicalDecodingProcessRecord(ctx=0x00007fba41835840,
record=0x00007fba41835b00) + 142 at decode.c:113   frame #11: 0x000000010253cc42
postgres`pg_logical_slot_get_changes_guts(fcinfo=0x00007fff5daf2530,
confirm='\0', binary='\0') + 2562 at logicalfuncs.c:308   frame #12: 0x000000010253cdbb
postgres`pg_logical_slot_peek_changes(fcinfo=0x00007fff5daf2530) + 27
at logicalfuncs.c:381
(lldb) up 1
frame #4: 0x000000010240c88b postgres`AtEOSubXact_SPI(isCommit='\0',
mySubid=2) + 811 at spi.c:297  294                 }  295             }  296             /* in particular we should
havegotten rid of any
 
in-progress table */
-> 297             Assert(_SPI_current->tuptable == NULL);  298         }  299     }  300

This looks like a legit bug to me. Andres, any opinions?
-- 
Michael


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs