Re: Pg 15 devel crashes when fetching data from table using cursor

Hi,

On 2022-03-10 21:40:05 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > interestingly a single row isn't sufficient to trigger it, even if it contains
> > data to be detoasted...

Argh, no, that was me confusing a compressed with an externally toasted row...

BEGIN;
DECLARE foo CURSOR FOR SELECT ev_action FROM pg_rewrite WHERE ev_class = 'information_schema.columns'::regclass;
FETCH FROM foo;

triggers the problem just as well (backtrace below).

> Hah, that explains why I failed to reproduce it a couple days ago.
> IIRC, I set up a test case with a one-row table :-(

Maybe that was something similar?

This suggests that we should assert that we have a suitable snapshot in
pg_detoast_datum*, so that we don't need to have an externally toasted datum
to notice such bugs. The reason I put it in init_toast_snapshot() was that the
bug leading to the assert was from toast_delete_datum(). But even there it'd
be better to put the assert to before the early return?

#0 ExceptionalCondition (conditionName=0x7f051dbfbca8 "HaveRegisteredOrActiveSnapshot()", errorType=0x7f051dbfb8e8 "FailedAssertion",
fileName=0x7f051dbfb8a0 "/home/andres/src/postgresql/src/backend/access/common/toast_internals.c", lineNumber=670)
at /home/andres/src/postgresql/src/backend/utils/error/assert.c:36
#1 0x00007f051d49a64d in init_toast_snapshot (toast_snapshot=0x7ffcfa83fe70) at /home/andres/src/postgresql/src/backend/access/common/toast_internals.c:670
#2 0x00007f051d50e7d7 in heap_fetch_toast_slice (toastrel=0x7f0494d940f8, valueid=12004, attrsize=2113, sliceoffset=0, slicelength=2113,
result=0x7f051feb8670) at /home/andres/src/postgresql/src/backend/access/heap/heaptoast.c:688
#3 0x00007f051d48ce9e in table_relation_fetch_toast_slice (toastrel=0x7f0494d940f8, valueid=12004, attrsize=2113, sliceoffset=0, slicelength=2113,
result=0x7f051feb8670) at /home/andres/src/postgresql/src/include/access/tableam.h:1892
#4 0x00007f051d48ddad in toast_fetch_datum (attr=0x7f051ff57b40) at /home/andres/src/postgresql/src/backend/access/common/detoast.c:375
#5 0x00007f051d48d26d in detoast_attr (attr=0x7f051ff57b40) at /home/andres/src/postgresql/src/backend/access/common/detoast.c:123
#6 0x00007f051db83d86 in pg_detoast_datum_packed (datum=0x7f051ff57b40) at /home/andres/src/postgresql/src/backend/utils/fmgr/fmgr.c:1757
#7 0x00007f051db35489 in text_to_cstring (t=0x7f051ff57b40) at /home/andres/src/postgresql/src/backend/utils/adt/varlena.c:225
#8 0x00007f051db36487 in textout (fcinfo=0x7ffcfa8401f0) at /home/andres/src/postgresql/src/backend/utils/adt/varlena.c:574
#9 0x00007f051dac0abc in pg_node_tree_out (fcinfo=0x7ffcfa8401f0) at /home/andres/src/postgresql/src/backend/utils/adt/pseudotypes.c:354
#10 0x00007f051db828c8 in FunctionCall1Coll (flinfo=0x7f051feb2018, collation=0, arg1=139659987745600)
at /home/andres/src/postgresql/src/backend/utils/fmgr/fmgr.c:1138
#11 0x00007f051db839d9 in OutputFunctionCall (flinfo=0x7f051feb2018, val=139659987745600) at /home/andres/src/postgresql/src/backend/utils/fmgr/fmgr.c:1575
#12 0x00007f051d494557 in printtup (slot=0x7f051feacfa8, self=0x7f051fe8b388) at /home/andres/src/postgresql/src/backend/access/common/printtup.c:357
#13 0x00007f051d9cf51f in RunFromStore (portal=0x7f051fef3ff0, direction=ForwardScanDirection, count=0, dest=0x7f051fe8b388)
at /home/andres/src/postgresql/src/backend/tcop/pquery.c:1096
#14 0x00007f051d9cf03b in PortalRunSelect (portal=0x7f051fef3ff0, forward=true, count=0, dest=0x7f051fe8b388)
at /home/andres/src/postgresql/src/backend/tcop/pquery.c:917
#15 0x00007f051d9ced02 in PortalRun (portal=0x7f051fef3ff0, count=9223372036854775807, isTopLevel=true, run_once=true, dest=0x7f051fe8b388,
altdest=0x7f051fe8b388, qc=0x7ffcfa840510) at /home/andres/src/postgresql/src/backend/tcop/pquery.c:765
#16 0x00007f051d9c8245 in exec_simple_query (query_string=0x7f051fe8a530 "FETCH FROM foo ;") at /home/andres/src/postgresql/src/backend/tcop/postgres.c:1250

Which indeed looks like a problem - there's no snapshot handling around
RunFromStore() (compare with ExecutorRun() invocation just after), but
FillPortalStore passes detoast=false to SetTuplestoreDestReceiverParams().

Greetings,

Andres Freund