Horton

Thread

Commits

  1. Restore the portal-level snapshot for simple expressions, too.

  2. Centralize the logic for protective copying of utility statements.

  3. Restore the portal-level snapshot after procedure COMMIT/ROLLBACK.

  4. Avoid taking a new snapshot for an immutable simple expression in plpgsql.

  1. Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Nasby, Jim <nasbyj@amazon.com> — 2021-06-21T23:19:27Z

    The following generates an assertion failure. Quick testing with start 
and stop as well as the core dump shows it’s failing on the execution of 
`schema_name := schema_name(i)` immediately after COMMIT, because 
there’s no active snapshot. On a build without asserts I get a failure 
in GetActiveSnapshot() (second stack trace). This works fine on 
12_STABLE, but fails on 13_STABLE and HEAD.


CREATE OR REPLACE FUNCTION public.schema_name(i integer)
  RETURNS text
  LANGUAGE sql
  IMMUTABLE
AS $function$
SELECT 'test_' || trim(to_char(i, '000000'))
$function$;

CREATE OR REPLACE PROCEDURE public.build_schema(start integer, stop 
integer, commit_interval integer DEFAULT 10, do_insert boolean DEFAULT true)
  LANGUAGE plpgsql
AS $procedure$
DECLARE
     schema_name text;
BEGIN
FOR i IN start .. stop LOOP
     schema_name := schema_name(i);
     IF i % commit_interval = 0 THEN
         --RAISE NOTICE 'COMMIT CREATE step %', i;
         COMMIT;
     END IF;
END LOOP;
END$procedure$;


CALL build_schema(1,11);


<assert failure>

Core file '/cores/core.1912' (x86_64) was loaded.

(lldb) bt
* thread #1, stop reason = signal SIGSTOP
   * frame #0: 0x00007fff6c3ae33a libsystem_kernel.dylib`__pthread_kill + 10
     frame #1: 0x00007fff6c46ae60 libsystem_pthread.dylib`pthread_kill + 430
     frame #2: 0x00007fff6c335808 libsystem_c.dylib`abort + 120
     frame #3: 0x000000010af1af6d 
postgres`ExceptionalCondition(conditionName="ActiveSnapshotSet()", 
errorType="FailedAssertion", fileName="postgres.c", lineNumber=867) at 
assert.c:67:2
     frame #4: 0x000000010ad3aeb3 
postgres`pg_plan_query(querytree=0x00007ff663023848, 
query_string="\nSELECT 'test_' || trim(to_char(i, '000000'))\n", 
cursorOptions=256, boundParams=0x0000000000000000) at postgres.c:867:2
     frame #5: 0x000000010aad9059 
postgres`init_execution_state(queryTree_list=0x00007ff663024208, 
fcache=0x00007ff663022720, lazyEvalOK=true) at functions.c:513:12
     frame #6: 0x000000010aad6dec 
postgres`init_sql_fcache(fcinfo=0x00007ff663035918, collation=0, 
lazyEvalOK=true) at functions.c:787:23
     frame #7: 0x000000010aad5ffa 
postgres`fmgr_sql(fcinfo=0x00007ff663035918) at functions.c:1070:3
     frame #8: 0x000000010aaaf660 
postgres`ExecInterpExpr(state=0x00007ff663035828, 
econtext=0x00007ff663035738, isnull=0x00007ffee5459bbf) at 
execExprInterp.c:680:8
     frame #9: 0x000000010aaae9b7 
postgres`ExecInterpExprStillValid(state=0x00007ff663035828, 
econtext=0x00007ff663035738, isNull=0x00007ffee5459bbf) at 
execExprInterp.c:1807:9
     frame #10: 0x00000001163e5b5a 
plpgsql.so`ExecEvalExpr(state=0x00007ff663035828, 
econtext=0x00007ff663035738, isNull=0x00007ffee5459bbf) at executor.h:303:9
     frame #11: 0x00000001163e4fe0 
plpgsql.so`exec_eval_simple_expr(estate=0x00007ffee545a080, 
expr=0x00007ff662032db0, result=0x00007ffee5459b68, 
isNull=0x00007ffee5459bbf, rettype=0x00007ffee5459bb8, 
rettypmod=0x00007ffee5459bb4) at pl_exec.c:6328:12
     frame #12: 0x00000001163e4887 
plpgsql.so`exec_eval_expr(estate=0x00007ffee545a080, 
expr=0x00007ff662032db0, isNull=0x00007ffee5459bbf, 
rettype=0x00007ffee5459bb8, rettypmod=0x00007ffee5459bb4) at 
pl_exec.c:5833:6
     frame #13: 0x00000001163e30c2 
plpgsql.so`exec_assign_expr(estate=0x00007ffee545a080, 
target=0x00007ff66300e4d0, expr=0x00007ff662032db0) at pl_exec.c:4973:10
     frame #14: 0x00000001163dc407 
plpgsql.so`exec_stmt_assign(estate=0x00007ffee545a080, 
stmt=0x00007ff662032e80) at pl_exec.c:2112:2
     frame #15: 0x00000001163d9de2 
plpgsql.so`exec_stmt(estate=0x00007ffee545a080, stmt=0x00007ff662032e80) 
at pl_exec.c:1980:9
     frame #16: 0x00000001163e3387 
plpgsql.so`exec_stmts(estate=0x00007ffee545a080, 
stmts=0x00007ff662032eb8) at pl_exec.c:1943:14
     frame #17: 0x00000001163ddd7c 
plpgsql.so`exec_stmt_fori(estate=0x00007ffee545a080, 
stmt=0x00007ff662032ca8) at pl_exec.c:2783:8
     frame #18: 0x00000001163d9ea2 
plpgsql.so`exec_stmt(estate=0x00007ffee545a080, stmt=0x00007ff662032ca8) 
at pl_exec.c:2012:9
     frame #19: 0x00000001163e3387 
plpgsql.so`exec_stmts(estate=0x00007ffee545a080, 
stmts=0x00007ff6620328d0) at pl_exec.c:1943:14
     frame #20: 0x00000001163dc20d 
plpgsql.so`exec_stmt_block(estate=0x00007ffee545a080, 
block=0x00007ff6620231c8) at pl_exec.c:1884:8
     frame #21: 0x00000001163d9dca 
plpgsql.so`exec_stmt(estate=0x00007ffee545a080, stmt=0x00007ff6620231c8) 
at pl_exec.c:1976:9
     frame #22: 0x00000001163d8393 
plpgsql.so`plpgsql_exec_function(func=0x00007ff666055738, 
fcinfo=0x00007ffee545a478, simple_eval_estate=0x0000000000000000, 
simple_eval_resowner=0x0000000000000000, atomic=false) at pl_exec.c:610:7
     frame #23: 0x00000001163f6c4a 
plpgsql.so`plpgsql_call_handler(fcinfo=0x00007ffee545a478) at 
pl_handler.c:265:13
     frame #24: 0x000000010aa22232 
postgres`ExecuteCallStmt(stmt=0x00007ff662010320, 
params=0x0000000000000000, atomic=false, dest=0x00007ff662010ba0) at 
functioncmds.c:2232:11
     frame #25: 0x000000010ad454af 
postgres`standard_ProcessUtility(pstmt=0x00007ff6620103e8, 
queryString="call build_schema (1,11);", 
context=PROCESS_UTILITY_TOPLEVEL, params=0x0000000000000000, 
queryEnv=0x0000000000000000, dest=0x00007ff662010ba0, 
qc=0x00007ffee545b070) at utility.c:817:4
     frame #26: 0x000000010ad44c82 
postgres`ProcessUtility(pstmt=0x00007ff6620103e8, queryString="call 
build_schema (1,11);", context=PROCESS_UTILITY_TOPLEVEL, 
params=0x0000000000000000, queryEnv=0x0000000000000000, 
dest=0x00007ff662010ba0, qc=0x00007ffee545b070) at utility.c:524:3
     frame #27: 0x000000010ad4443e 
postgres`PortalRunUtility(portal=0x00007ff66282f320, 
pstmt=0x00007ff6620103e8, isTopLevel=true, setHoldSnapshot=false, 
dest=0x00007ff662010ba0, qc=0x00007ffee545b070) at pquery.c:1145:2
     frame #28: 0x000000010ad4359d 
postgres`PortalRunMulti(portal=0x00007ff66282f320, isTopLevel=true, 
setHoldSnapshot=false, dest=0x00007ff662010ba0, 
altdest=0x00007ff662010ba0, qc=0x00007ffee545b070) at pquery.c:1301:5
     frame #29: 0x000000010ad42b2e 
postgres`PortalRun(portal=0x00007ff66282f320, count=9223372036854775807, 
isTopLevel=true, run_once=true, dest=0x00007ff662010ba0, 
altdest=0x00007ff662010ba0, qc=0x00007ffee545b070) at pquery.c:786:5
     frame #30: 0x000000010ad3e0c5 
postgres`exec_simple_query(query_string="call build_schema (1,11);") at 
postgres.c:1239:10
     frame #31: 0x000000010ad3d26d postgres`PostgresMain(argc=1, 
argv=0x00007ff66280f670, dbname="nasbyj", username="nasbyj") at 
postgres.c:4339:7
     frame #32: 0x000000010ac6752a 
postgres`BackendRun(port=0x00007ff664404080) at postmaster.c:4526:2
     frame #33: 0x000000010ac66979 
postgres`BackendStartup(port=0x00007ff664404080) at postmaster.c:4210:3
     frame #34: 0x000000010ac658fd postgres`ServerLoop at 
postmaster.c:1739:7
     frame #35: 0x000000010ac633e4 postgres`PostmasterMain(argc=1, 
argv=0x00007ff661c06cc0) at postmaster.c:1412:11
     frame #36: 0x000000010ab45679 postgres`main(argc=1, 
argv=0x00007ff661c06cc0) at main.c:210:3
     frame #37: 0x00007fff6c266cc9 libdyld.dylib`start + 1
     frame #38: 0x00007fff6c266cc9 libdyld.dylib`start + 1
(lldb) fr 4
invalid command 'frame 4'.
(lldb) fr s 4
frame #4: 0x000000010ad3aeb3 
postgres`pg_plan_query(querytree=0x00007ff663023848, 
query_string="\nSELECT 'test_' || trim(to_char(i, '000000'))\n", 
cursorOptions=256, boundParams=0x0000000000000000) at postgres.c:867:2
    864             return NULL;
    865
    866         /* Planner must have a snapshot in case it calls 
user-defined functions. */
-> 867         Assert(ActiveSnapshotSet());
    868
    869         TRACE_POSTGRESQL_QUERY_PLAN_START();
    870
(lldb)


... non-assert build ...


(lldb) bt
postgres was compiled with optimization - stepping may behave oddly; 
variables may not be available.
* thread #1, stop reason = signal SIGSTOP
   * frame #0: 0x0000000101d207db postgres`GetActiveSnapshot at 
snapmgr.c:845:25 [opt]
     frame #1: 0x0000000101a83f25 postgres`fmgr_sql [inlined] 
postquel_start(es=0x00007fd19789c5a8, fcache=<unavailable>) at 
functions.c:832:9 [opt]
     frame #2: 0x0000000101a83ec6 
postgres`fmgr_sql(fcinfo=<unavailable>) at functions.c:1161 [opt]
     frame #3: 0x0000000101a6fae1 
postgres`ExecInterpExpr(state=<unavailable>, econtext=<unavailable>, 
isnull=0x00007ffeee304a57) at execExprInterp.c:680:8 [opt]
     frame #4: 0x00000001028ddc10 plpgsql.so`exec_eval_expr [inlined] 
ExecEvalExpr(state=<unavailable>, econtext=0x00007fd19a818128, 
isNull=0x00007ffeee304a57) at executor.h:303:9 [opt]
     frame #5: 0x00000001028ddc06 plpgsql.so`exec_eval_expr [inlined] 
exec_eval_simple_expr(estate=0x00007ffeee304f18, 
expr=0x00007fd1980268c0, isNull=<unavailable>, rettype=<unavailable>, 
rettypmod=0x00007fd19a80fe00) at pl_exec.c:6328 [opt]
     frame #6: 0x00000001028ddb2a 
plpgsql.so`exec_eval_expr(estate=0x00007ffeee304f18, 
expr=0x00007fd1980268c0, isNull=<unavailable>, rettype=<unavailable>, 
rettypmod=0x00007fd19a80fe00) at pl_exec.c:5833 [opt]
     frame #7: 0x00000001028dd258 
plpgsql.so`exec_assign_expr(estate=0x00007ffeee304f18, 
target=0x00007fd19a810120, expr=0x00007fd1980268c0) at pl_exec.c:4973:10 
[opt]
     frame #8: 0x00000001028d86a2 plpgsql.so`exec_stmt [inlined] 
exec_stmt_assign(estate=0x00007ffeee304f18, stmt=0x00007fd198026980) at 
pl_exec.c:2112:2 [opt]
     frame #9: 0x00000001028d868a 
plpgsql.so`exec_stmt(estate=0x00007ffeee304f18, stmt=0x00007fd198026980) 
at pl_exec.c:1980 [opt]
     frame #10: 0x00000001028d9941 plpgsql.so`exec_stmt at 
pl_exec.c:1943:14 [opt]
     frame #11: 0x00000001028d9914 plpgsql.so`exec_stmt [inlined] 
exec_stmt_fori(estate=0x00007ffeee304f18, stmt=0x00007fd1980267d8) at 
pl_exec.c:2783 [opt]
     frame #12: 0x00000001028d98a9 
plpgsql.so`exec_stmt(estate=<unavailable>, stmt=<unavailable>) at 
pl_exec.c:2012 [opt]
     frame #13: 0x00000001028dbf20 plpgsql.so`exec_stmt_block at 
pl_exec.c:1943:14 [opt]
     frame #14: 0x00000001028dbefb 
plpgsql.so`exec_stmt_block(estate=0x00007ffeee304f18, 
block=0x00007fd198026c20) at pl_exec.c:1884 [opt]
     frame #15: 0x00000001028d7ec3 
plpgsql.so`exec_stmt(estate=0x00007ffeee304f18, stmt=0x00007fd198026c20) 
at pl_exec.c:1976:9 [opt]
     frame #16: 0x00000001028d6f45 
plpgsql.so`plpgsql_exec_function(func=0x00007fd19785cc60, 
fcinfo=0x00007ffeee3051f0, simple_eval_estate=<unavailable>, 
simple_eval_resowner=<unavailable>, atomic=<unavailable>) at 
pl_exec.c:610:7 [opt]
     frame #17: 0x00000001028e9122 
plpgsql.so`plpgsql_call_handler(fcinfo=0x00007ffeee3051f0) at 
pl_handler.c:265:13 [opt]
     frame #18: 0x0000000101a2b5e4 
postgres`ExecuteCallStmt(stmt=0x00007fd1978102b0, 
params=0x00007fd19a80f4e8, atomic=<unavailable>, 
dest=0x00007fd1978108d0) at functioncmds.c:2232:11 [opt]
     frame #19: 0x0000000101bd31f5 
postgres`standard_ProcessUtility(pstmt=0x00007fd197810360, 
queryString="CALL build_schema(1,11);", 
context=PROCESS_UTILITY_TOPLEVEL, params=0x0000000000000000, 
queryEnv=0x0000000000000000, dest=0x00007fd1978108d0, 
qc=0x00007ffeee305b80) at utility.c:817:4 [opt]
     frame #20: 0x0000000101bd2c58 
postgres`ProcessUtility(pstmt=0x00007fd197810360, 
queryString=<unavailable>, context=<unavailable>, params=<unavailable>, 
queryEnv=<unavailable>, dest=<unavailable>, qc=0x00007ffeee305b80) at 
utility.c:524:3 [opt]
     frame #21: 0x0000000101bd29b1 
postgres`PortalRunUtility(portal=0x00007fd197838118, 
pstmt=0x00007fd197810360, isTopLevel=<unavailable>, 
setHoldSnapshot=<unavailable>, dest=<unavailable>, 
qc=0x00007ffeee305b80) at pquery.c:1145:2 [opt]
     frame #22: 0x0000000101bd2028 
postgres`PortalRunMulti(portal=0x00007fd197838118, isTopLevel=true, 
setHoldSnapshot=false, dest=0x00007fd1978108d0, 
altdest=0x00007fd1978108d0, qc=<unavailable>) at pquery.c:0 [opt]
     frame #23: 0x0000000101bd1afd 
postgres`PortalRun(portal=0x00007fd197838118, count=9223372036854775807, 
isTopLevel=true, run_once=<unavailable>, dest=0x00007fd1978108d0, 
altdest=0x00007fd1978108d0, qc=0x00007ffeee305b80) at pquery.c:786:5 [opt]
     frame #24: 0x0000000101bd0d5a 
postgres`exec_simple_query(query_string="CALL build_schema(1,11);") at 
postgres.c:1239:10 [opt]
     frame #25: 0x0000000101bce608 
postgres`PostgresMain(argc=<unavailable>, argv=<unavailable>, 
dbname=<unavailable>, username=<unavailable>) at postgres.c:0 [opt]
     frame #26: 0x0000000101b57e11 
postgres`BackendRun(port=<unavailable>) at postmaster.c:4526:2 [opt]
     frame #27: 0x0000000101b57590 postgres`ServerLoop [inlined] 
BackendStartup(port=<unavailable>) at postmaster.c:4210:3 [opt]
     frame #28: 0x0000000101b5756f postgres`ServerLoop at 
postmaster.c:1739 [opt]
     frame #29: 0x0000000101b5474a 
postgres`PostmasterMain(argc=<unavailable>, argv=0x00007fd197406cc0) at 
postmaster.c:1412:11 [opt]
     frame #30: 0x0000000101abf3ef postgres`main(argc=<unavailable>, 
argv=<unavailable>) at main.c:210:3 [opt]
     frame #31: 0x00007fff6c266cc9 libdyld.dylib`start + 1
     frame #32: 0x00007fff6c266cc9 libdyld.dylib`start + 1
(lldb)

  2. Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Michael Paquier <michael@paquier.xyz> — 2021-06-22T06:34:20Z

    On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
> The following generates an assertion failure. Quick testing with start and
> stop as well as the core dump shows it’s failing on the execution of
> `schema_name := schema_name(i)` immediately after COMMIT, because there’s no
> active snapshot. On a build without asserts I get a failure in
> GetActiveSnapshot() (second stack trace). This works fine on 12_STABLE, but
> fails on 13_STABLE and HEAD.

A bisect run points me to the following commit:
commit 73b06cf893c9d3bb38c11878a12cc29407e78b6c
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Fri Nov 22 15:02:18 2019 -0500

Avoid taking a new snapshot for an immutable simple expression in plpgsql.

Snapshots would be taken when using non-immutable functions.  I'd need
to study more this code to grab if we could improve the situation
after committing the transaction, but, Tom, shouldn't we enforce a
snapshot in the case where the expression has not been prepared for
execution in the new XACT, even for the immutable case?  It seems to 
me that this refers to the case where expr_simple_lxid is still
invalid, no?
--
Michael

  3. Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-22T14:58:42Z

    Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
>> The following generates an assertion failure.

> A bisect run points me to the following commit:
> commit 73b06cf893c9d3bb38c11878a12cc29407e78b6c
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Date:   Fri Nov 22 15:02:18 2019 -0500
> Avoid taking a new snapshot for an immutable simple expression in plpgsql.

Hmm.  I think the real issue here is that commit 84f5c2908 did
not cover the "simple expression" code path in plpgsql.  We
need to re-establish an outer snapshot when the next thing
that happens after COMMIT is a simple expression, too.

In this view, 73b06cf8 just removed code that was masking the
lack of a snapshot during the evaluation of the simple expr
itself.  However, we'd still have had a problem if the simple
expr returned a toast pointer that we had to dereference after
returning (and popping that snapshot).  So I'm thinking
back-patch to v11, as before.

			regards, tom lane

  4. Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-22T15:48:46Z

    I wrote:
> Hmm.  I think the real issue here is that commit 84f5c2908 did
> not cover the "simple expression" code path in plpgsql.  We
> need to re-establish an outer snapshot when the next thing
> that happens after COMMIT is a simple expression, too.

The attached seems to be enough to resolve Jim's example.  I'd like
to invent a test case that involves a detoast of the simple
expression's result, too, to show that transiently pushing a
snapshot for the duration of the expression is not the right fix.

			regards, tom lane

  5. Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-22T17:13:08Z

    I wrote:
> The attached seems to be enough to resolve Jim's example.  I'd like
> to invent a test case that involves a detoast of the simple
> expression's result, too, to show that transiently pushing a
> snapshot for the duration of the expression is not the right fix.

Here we go.  This test case gives "cannot fetch toast data without an
active snapshot" in v11 and v12 branch tips.  Since those branches lack
the 73b06cf89 optimization, they push a snapshot while calling the
SQL-language function, thus it doesn't complain.  But what comes back
is toasted, and then we fail trying to detoast it.

			regards, tom lane

  6. Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Justin Pryzby <pryzby@telsasoft.com> — 2021-06-23T03:59:16Z

    On Tue, Jun 22, 2021 at 01:13:08PM -0400, Tom Lane wrote:
> I wrote:
> > The attached seems to be enough to resolve Jim's example.  I'd like
> > to invent a test case that involves a detoast of the simple
> > expression's result, too, to show that transiently pushing a
> > snapshot for the duration of the expression is not the right fix.
> 
> Here we go.  This test case gives "cannot fetch toast data without an
> active snapshot" in v11 and v12 branch tips.  Since those branches lack
> the 73b06cf89 optimization, they push a snapshot while calling the
> SQL-language function, thus it doesn't complain.  But what comes back
> is toasted, and then we fail trying to detoast it.

This causes the server to crash during FETCH.

ts=# begin; declare b cursor for VALUES(1); fetch 100 in b;
BEGIN
DECLARE CURSOR
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

7c337b6b527b7052e6a751f966d5734c56f668b5 is the first bad commit
|	commit 7c337b6b527b7052e6a751f966d5734c56f668b5
|	Author: Tom Lane <tgl@sss.pgh.pa.us>
|	Date:   Fri Jun 18 11:22:58 2021 -0400
|
|	    Centralize the logic for protective copying of utility statements.

I noticed because it was tickled by pg_dump.

[109037.576659] postgres[32358]: segfault at 9a ip 00007f86a68fa7b1 sp 00007fffd5ae2a88 error 4 in libc-2.17.so[7f86a678b000+1c4000]

< 2021-06-22 20:00:06.557 EDT  >LOG:  server process (PID 32358) was terminated by signal 11: Segmentation fault
< 2021-06-22 20:00:06.557 EDT  >DETAIL:  Failed process was running: FETCH 1000 IN bloboid

Core was generated by `postgres: postgres ts [local] FETCH                          '.

(gdb) bt
#0  0x00007f86a68fa7b1 in __strlen_sse2_pminub () from /lib64/libc.so.6
#1  0x00000000008f7151 in string_hash (key=0x9a, keysize=64) at hashfn.c:667
#2  0x00000000008c1dd0 in hash_search (hashp=0x1534168, keyPtr=0x9a, action=action@entry=HASH_REMOVE, foundPtr=foundPtr@entry=0x0) at dynahash.c:959
#3  0x00000000008df29b in PortalDrop (portal=0x1532158, isTopCommit=<optimized out>) at portalmem.c:514
#4  0x00000000007959a7 in exec_simple_query (query_string=0x14bce88 "FETCH 1000 IN bloboid") at postgres.c:1224
#5  0x0000000000796e2d in PostgresMain (argc=argc@entry=1, argv=argv@entry=0x7fffd5ae2ff0, dbname=0x14b9a78 "ts", username=<optimized out>) at postgres.c:4486
#6  0x00000000004890c1 in BackendRun (port=<optimized out>, port=<optimized out>) at postmaster.c:4507
#7  BackendStartup (port=0x14e4280) at postmaster.c:4229
#8  ServerLoop () at postmaster.c:1745
#9  0x0000000000718dcd in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x14b79e0) at postmaster.c:1417
#10 0x0000000000489f32 in main (argc=3, argv=0x14b79e0) at main.c:209

(gdb) p *portal
$1 = {name = 0x9a <Address 0x9a out of bounds>, prepStmtName = 0x0, portalContext = 0x15f5b00, resowner = 0x14f7d50, cleanup = 0x0, createSubid = 1, activeSubid = 1,
  sourceText = 0x14bce88 "FETCH 1000 IN bloboid", commandTag = CMDTAG_FETCH, qc = {commandTag = CMDTAG_FETCH, nprocessed = 0}, stmts = 0x14bdc58, cplan = 0x0,
  portalParams = 0x0, queryEnv = 0x0, strategy = PORTAL_UTIL_SELECT, cursorOptions = 4, run_once = true, status = PORTAL_READY, portalPinned = false, autoHeld = false,
  queryDesc = 0x0, tupDesc = 0x15f5c18, formats = 0x15f5d28, portalSnapshot = 0x0, holdStore = 0x165d688, holdContext = 0x165d570, holdSnapshot = 0x0, atStart = true,
  atEnd = true, portalPos = 0, creation_time = 677721606449684, visible = false}

  7. Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-23T04:07:11Z

    Justin Pryzby <pryzby@telsasoft.com> writes:
> This causes the server to crash during FETCH.

> ts=# begin; declare b cursor for VALUES(1); fetch 100 in b;
> BEGIN
> DECLARE CURSOR
> server closed the connection unexpectedly
>         This probably means the server terminated abnormally
>         before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.

Hm, works for me:

regression=# begin; declare b cursor for VALUES(1); fetch 100 in b;
BEGIN
DECLARE CURSOR
 column1 
---------
       1
(1 row)

			regards, tom lane

  8. Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

    Justin Pryzby <pryzby@telsasoft.com> — 2021-06-23T04:25:18Z

    On Wed, Jun 23, 2021 at 12:07:11AM -0400, Tom Lane wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > This causes the server to crash during FETCH.
> 
> > ts=# begin; declare b cursor for VALUES(1); fetch 100 in b;
> > BEGIN
> > DECLARE CURSOR
> > server closed the connection unexpectedly
> >         This probably means the server terminated abnormally
> >         before or while processing the request.
> > The connection to the server was lost. Attempting reset: Failed.
> 
> Hm, works for me:

I think it's because I had old pg_stat_statements module, and hadn't make -C contrib.

Sorry for the noise.

-- 
Justin