Message-ID: <a8631020-6b7c-4a38-9ae6-de061e3c9573@iki.fi>
Date: Wed, 11 Mar 2026 18:00:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19427: TOAST Snapshot Assertion Failure
To: 303677365@qq.com, pgsql-bugs@lists.postgresql.org
References: <19427-44560ddf098e6489@postgresql.org>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <19427-44560ddf098e6489@postgresql.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/a8631020-6b7c-4a38-9ae6-de061e3c9573%40iki.fi>
Precedence: bulk

On 11/03/2026 11:21, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      19427
> Logged by:          chunling qin
> Email address:      303677365@qq.com
> PostgreSQL version: 15.0

15.13 is the newest on the v15 branch, 15.0 is no longer interesting. 
Did you mean a later minor version?

> Operating system:   centos
> Description:
> 
> ## Description
> 
> PostgreSQL crashes with an assertion failure when executing UPDATE
> statements with RETURNING clause that returns TOAST-compressed data
> (specifically `pg_node_tree` type from system catalogs). The assertion
> `HaveRegisteredOrActiveSnapshot()` fails in `init_toast_snapshot()`
> function.

Hmm, init_toast_snapshot() was removed in later versions, but the 
HaveRegisteredOrActiveSnapshot() is still present as a runtime check in 
the get_toast_snapshot() function that replaced it.

> ## Crash Information
> 
> ### Signal
> ```
> SIGABRT (Assertion failure)
> ```
> 
> ### Stack Trace
> ```
> #0  __pthread_kill_implementation () from /lib64/libc.so.6
> #1  raise () from /lib64/libc.so.6
> #2  abort () from /lib64/libc.so.6
> #3  ExceptionalCondition (conditionName="HaveRegisteredOrActiveSnapshot()",
>                            errorType="FailedAssertion",
>                            fileName="toast_internals.c", lineNumber=670)
> #4  init_toast_snapshot (toast_snapshot=0x7ffd01b64e50) at
> toast_internals.c:670
> #5  heap_fetch_toast_slice (toastrel=..., valueid=12032, attrsize=2448,
>                              sliceoffset=0, slicelength=2448, result=...)
>                              at heaptoast.c:688
> #6  table_relation_fetch_toast_slice (...) at tableam.h:1892
> #7  toast_fetch_datum (attr=...) at detoast.c:375
> #8  detoast_attr (attr=...) at detoast.c:123
> #9  pg_detoast_datum_packed (datum=...) at fmgr.c:1757
> #10 text_to_cstring (t=...) at varlena.c:225
> #11 textout (fcinfo=...) at varlena.c:574
> #12 pg_node_tree_out (fcinfo=...) at pseudotypes.c:354
> #13 FunctionCall1Coll (...) at fmgr.c:1138
> #14 OutputFunctionCall (...) at fmgr.c:1575
> #15 printtup (...) at printtup.c:357
> ```

Can you post the full stacktrace, with frames > 15 included, please?

> ## Reproduction
> 
> ### Minimal Test Case
> ```sql
> -- Case 1: UPDATE system catalog with RETURNING TOAST column
> UPDATE pg_catalog.pg_rewrite SET rulename = rulename
> WHERE oid = (SELECT oid FROM pg_catalog.pg_rewrite LIMIT 1)
> RETURNING ev_action;
> 
> -- Case 2: UPDATE with subquery returning TOAST data
> CREATE TABLE test_table (id int, col_varchar varchar);
> INSERT INTO test_table VALUES (1, 'test');
> 
> UPDATE test_table SET id = id
> RETURN
>      id,
>      (SELECT ev_action FROM pg_catalog.pg_rewrite LIMIT 1) AS ev_action;
> ```

I cannot reproduce this.

Is either one of "Case 1" or "Case 2" supposed to hit the assertion? Or 
do you need to run both?

The latter "UPDATE ... RETURN ..." is incorrect syntax, I presume it's 
supposed to be "UPDATE ... RETURNING ...". With that it runs without 
error here.

- Heikki