Re: pg_logical_slot_peek_changes crashes postgres when called from inside pl/pgsql

On Thu, Oct 5, 2017 at 5:59 AM, Ben Chobot <bench(at)silentmedia(dot)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 have gotten 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