pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
6+ messages / 4 participants
[nested] [flat]
* BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
@ 2024-02-21 12:00 PG Bug reporting form <noreply@postgresql.org>
2024-02-22 02:46 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: PG Bug reporting form @ 2024-02-21 12:00 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: exclusion@gmail.com
The following bug has been logged on the website:
Bug reference: 18354
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 16.2
Operating system: Ubuntu 22.04
Description:
The following script:
SET temp_file_limit = 100;
CREATE TABLE t (a text);
INSERT INTO t VALUES ('test');
SELECT 'INSERT INTO t SELECT * FROM t RETURNING *' FROM generate_series(1,
18)
\gexec
triggers two errors, a warning, and an assertion failure:
ERROR: temporary file size exceeds temp_file_limit (100kB)
WARNING: AbortTransaction while in ABORT state
ERROR: temporary file size exceeds temp_file_limit (100kB)
server closed the connection unexpectedly
The backtrace for the first error is:
2024-02-21 11:40:06.947 UTC|law|regression|65d5e116.13cfcb|LOG: statement:
INSERT INTO t SELECT * FROM t RETURNING *
2024-02-21 11:40:06.999 UTC|law|regression|65d5e116.13cfcb|ERROR: temporary
file size exceeds temp_file_limit (100kB)
2024-02-21 11:40:06.999 UTC|law|regression|65d5e116.13cfcb|BACKTRACE:
FileWrite at fd.c:2183:5
BufFileDumpBuffer at buffile.c:537:18
BufFileWrite at buffile.c:698:28
writetup_heap at tuplestore.c:1513:5
dumptuples at tuplestore.c:1210:35
tuplestore_puttuple_common at tuplestore.c:833:4
MemoryContextSwitchTo at palloc.h:142:23
(inlined by) tuplestore_puttupleslot at tuplestore.c:722:2
tstoreReceiveSlot_notoast at tstoreReceiver.c:129:1
ExecutePlan at execMain.c:1701:7
standard_ExecutorRun at execMain.c:365:3
ExecutorRun at execMain.c:310:1
ProcessQuery at pquery.c:165:5
PortalRunMulti at pquery.c:1293:7
FillPortalStore at pquery.c:1042:8
PortalRun at pquery.c:763:6
exec_simple_query at postgres.c:1282:3
PostgresMain at postgres.c:4641:27
report_fork_failure_to_client at postmaster.c:4242:1
BackendStartup at postmaster.c:4199:22
ServerLoop at postmaster.c:1788:6
main at main.c:185:3
For the second error:
2024-02-21 11:40:07.001 UTC|law|regression|65d5e116.13cfcb|ERROR: temporary
file size exceeds temp_file_limit (100kB)
2024-02-21 11:40:07.001 UTC|law|regression|65d5e116.13cfcb|BACKTRACE:
FileWrite at fd.c:2183:5
BufFileDumpBuffer at buffile.c:537:18
BufFileFlush at buffile.c:723:3
BufFileClose at buffile.c:419:9
tuplestore_end at tuplestore.c:459:5
MemoryContextSwitchTo at palloc.h:142:23
(inlined by) PortalDrop at portalmem.c:587:3
AtCleanup_Portals at portalmem.c:907:3
CleanupTransaction at xact.c:2903:2
AbortCurrentTransaction at xact.c:3341:18
PostgresMain at postgres.c:4356:6
report_fork_failure_to_client at postmaster.c:4242:1
BackendStartup at postmaster.c:4199:22
ServerLoop at postmaster.c:1788:6
main at main.c:185:3
For the failed assertion:
2024-02-21 11:40:07.001 UTC|law|regression|65d5e116.13cfcb|WARNING:
AbortTransaction while in ABORT state
TRAP: failed Assert("TransactionIdIsValid(proc->xid)"), File: "procarray.c",
Line: 680, PID: 1298379
ExceptionalCondition at assert.c:52:13
ProcArrayEndTransactionInternal at procarray.c:742:2
(inlined by) ProcArrayEndTransaction at procarray.c:689:4
AbortTransaction at xact.c:2841:5
AbortCurrentTransaction at xact.c:3340:4
PostgresMain at postgres.c:4356:6
report_fork_failure_to_client at postmaster.c:4242:1
BackendStartup at postmaster.c:4199:22
ServerLoop at postmaster.c:1788:6
BackgroundWorkerInitializeConnection at postmaster.c:5604:1
main at main.c:185:3
Reproduced on REL_12_STABLE .. master.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
2024-02-21 12:00 BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded PG Bug reporting form <noreply@postgresql.org>
@ 2024-02-22 02:46 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 03:49 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Tender Wang <tndrwang@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Kyotaro Horiguchi @ 2024-02-22 02:46 UTC (permalink / raw)
To: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
At Wed, 21 Feb 2024 12:00:01 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in
> triggers two errors, a warning, and an assertion failure:
> ERROR: temporary file size exceeds temp_file_limit (100kB)
> WARNING: AbortTransaction while in ABORT state
> ERROR: temporary file size exceeds temp_file_limit (100kB)
> server closed the connection unexpectedly
...
> For the second error:
> 2024-02-21 11:40:07.001 UTC|law|regression|65d5e116.13cfcb|ERROR: temporary
> file size exceeds temp_file_limit (100kB)
> 2024-02-21 11:40:07.001 UTC|law|regression|65d5e116.13cfcb|BACKTRACE:
> FileWrite at fd.c:2183:5
> BufFileDumpBuffer at buffile.c:537:18
> BufFileFlush at buffile.c:723:3
> BufFileClose at buffile.c:419:9
> tuplestore_end at tuplestore.c:459:5
> MemoryContextSwitchTo at palloc.h:142:23
> (inlined by) PortalDrop at portalmem.c:587:3
> AtCleanup_Portals at portalmem.c:907:3
Therefore, BufFileClose should not flush the content during error
handling. In the first place, tuplestore doesn't need to flush the
underlying files in _end and _clear. In this case, I would choose to
change the general behavior of tuplestore. The attached PoC patch
fixes the issue for me. It introduces a new "extended" function to
control flushing, avoiding the addition of an unnatural parameter to
BufFileClose. I suspect that it is usable in some other places, but I
haven't checked that.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachments:
[text/x-patch] don_t_flush_tuplestore_at_end.diff (2.0K, ../../20240222.114600.1019580904613326727.horikyota.ntt@gmail.com/2-don_t_flush_tuplestore_at_end.diff)
download | inline diff:
diff --git a/src/backend/storage/file/buffile.c b/src/backend/storage/file/buffile.c
index 5315d8a714..9dae2e512f 100644
--- a/src/backend/storage/file/buffile.c
+++ b/src/backend/storage/file/buffile.c
@@ -410,11 +410,21 @@ BufFileExportFileSet(BufFile *file)
*/
void
BufFileClose(BufFile *file)
+{
+ BufFileCloseExtended(file, true);
+}
+
+/*
+ * Close a BufFile with specifying wheter the content is flushed out
+ */
+void
+BufFileCloseExtended(BufFile *file, bool flush)
{
int i;
- /* flush any unwritten data */
- BufFileFlush(file);
+ /* flush any unwritten data if requested */
+ if (flush)
+ BufFileFlush(file);
/* close and delete the underlying file(s) */
for (i = 0; i < file->numFiles; i++)
FileClose(file->files[i]);
diff --git a/src/backend/utils/sort/tuplestore.c b/src/backend/utils/sort/tuplestore.c
index 947a868e56..08c1bcced9 100644
--- a/src/backend/utils/sort/tuplestore.c
+++ b/src/backend/utils/sort/tuplestore.c
@@ -421,7 +421,7 @@ tuplestore_clear(Tuplestorestate *state)
TSReadPointer *readptr;
if (state->myfile)
- BufFileClose(state->myfile);
+ BufFileCloseExtended(state->myfile, false);
state->myfile = NULL;
if (state->memtuples)
{
@@ -455,7 +455,7 @@ tuplestore_end(Tuplestorestate *state)
int i;
if (state->myfile)
- BufFileClose(state->myfile);
+ BufFileCloseExtended(state->myfile, false);
if (state->memtuples)
{
for (i = state->memtupdeleted; i < state->memtupcount; i++)
diff --git a/src/include/storage/buffile.h b/src/include/storage/buffile.h
index 5f6d7c8e3f..d4796f9cb4 100644
--- a/src/include/storage/buffile.h
+++ b/src/include/storage/buffile.h
@@ -38,6 +38,7 @@ typedef struct BufFile BufFile;
extern BufFile *BufFileCreateTemp(bool interXact);
extern void BufFileClose(BufFile *file);
+extern void BufFileCloseExtended(BufFile *file, bool flush);
extern pg_nodiscard size_t BufFileRead(BufFile *file, void *ptr, size_t size);
extern void BufFileReadExact(BufFile *file, void *ptr, size_t size);
extern size_t BufFileReadMaybeEOF(BufFile *file, void *ptr, size_t size, bool eofOK);
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
2024-02-21 12:00 BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded PG Bug reporting form <noreply@postgresql.org>
2024-02-22 02:46 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
@ 2024-02-22 03:49 ` Tender Wang <tndrwang@gmail.com>
2024-02-22 05:38 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Tender Wang @ 2024-02-22 03:49 UTC (permalink / raw)
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
When the first error was reported, we entered AbortTransaction(),
proc->xid was changed to InvalidTransactionId
in ProcArrayEndTransactionInternal().
After AbortTransaction() is done, we enter into CleanupTransaction(), and
error would be reported again. So we enter AbortTransaction() again because
the transaction block state is still TBLOCK_STARTED. MyProc->xid now is
InvalidTransactionId, so the assert failed.
Changing the behavior of tuplestore can work for this issue, but I'm not
sure if this change will affect other components which depend on
BufFile(like nodeMaterial)
Kyotaro Horiguchi <horikyota.ntt@gmail.com> 于2024年2月22日周四 10:46写道：
> At Wed, 21 Feb 2024 12:00:01 +0000, PG Bug reporting form <
> noreply@postgresql.org> wrote in
> > triggers two errors, a warning, and an assertion failure:
> > ERROR: temporary file size exceeds temp_file_limit (100kB)
> > WARNING: AbortTransaction while in ABORT state
> > ERROR: temporary file size exceeds temp_file_limit (100kB)
> > server closed the connection unexpectedly
> ...
> > For the second error:
> > 2024-02-21 11:40:07.001 UTC|law|regression|65d5e116.13cfcb|ERROR:
> temporary
> > file size exceeds temp_file_limit (100kB)
> > 2024-02-21 11:40:07.001 UTC|law|regression|65d5e116.13cfcb|BACKTRACE:
> > FileWrite at fd.c:2183:5
> > BufFileDumpBuffer at buffile.c:537:18
> > BufFileFlush at buffile.c:723:3
> > BufFileClose at buffile.c:419:9
> > tuplestore_end at tuplestore.c:459:5
> > MemoryContextSwitchTo at palloc.h:142:23
> > (inlined by) PortalDrop at portalmem.c:587:3
> > AtCleanup_Portals at portalmem.c:907:3
>
> Therefore, BufFileClose should not flush the content during error
> handling. In the first place, tuplestore doesn't need to flush the
> underlying files in _end and _clear. In this case, I would choose to
> change the general behavior of tuplestore. The attached PoC patch
> fixes the issue for me. It introduces a new "extended" function to
> control flushing, avoiding the addition of an unnatural parameter to
> BufFileClose. I suspect that it is usable in some other places, but I
> haven't checked that.
>
> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
--
Tender Wang
OpenPie: https://en.openpie.com/
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
2024-02-21 12:00 BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded PG Bug reporting form <noreply@postgresql.org>
2024-02-22 02:46 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 03:49 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Tender Wang <tndrwang@gmail.com>
@ 2024-02-22 05:38 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 07:00 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Kyotaro Horiguchi @ 2024-02-22 05:38 UTC (permalink / raw)
To: tndrwang@gmail.com; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
At Thu, 22 Feb 2024 11:49:29 +0800, Tender Wang <tndrwang@gmail.com> wrote in
> Changing the behavior of tuplestore can work for this issue, but I'm not
> sure if this change will affect other components which depend on
> BufFile(like nodeMaterial)
Right. Regarding this type of error, the best we can do is to be
careful not to cause exceptions (elog/ereport(>=ERROR)) within the
abort code path. This is somewhat similar to the case of the
interaction between malloc() and signal handler.
First I tried to skip flushing in BufFileClose based on transaction
state and isInterXact state. However, that didn't seem that simple. We
could provide some flag to signal we're in the state where we cannot
error out, which BufFileClose refers to. That in turn can cause other
issues.
I mentioned that I haven't checked for the similar potential issues
BufFileClose can cause, but if nodeMaterial is that, the new function
could be usable for that.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
2024-02-21 12:00 BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded PG Bug reporting form <noreply@postgresql.org>
2024-02-22 02:46 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 03:49 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Tender Wang <tndrwang@gmail.com>
2024-02-22 05:38 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
@ 2024-02-22 07:00 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2026-05-06 11:26 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Alex Masterov <amasterov@gmail.com>
0 siblings, 1 reply; 6+ messages in thread
From: Kyotaro Horiguchi @ 2024-02-22 07:00 UTC (permalink / raw)
To: tndrwang@gmail.com; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
At Thu, 22 Feb 2024 14:38:15 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
> At Thu, 22 Feb 2024 11:49:29 +0800, Tender Wang <tndrwang@gmail.com> wrote in
> > Changing the behavior of tuplestore can work for this issue, but I'm not
> > sure if this change will affect other components which depend on
> > BufFile(like nodeMaterial)
In the case of nodeMaterial, tuplestore is simply discarded and
underlying files are removed without flushing by the resource owner
mechanism. On the other hand, in the case of this bug report, the
files in the problem tuplestore are not managed by a resource
owner. As a result, PortalDrop have to explicitly call tuplestore_end
to release resources used by the tuplestore.
> /*
> * Delete tuplestore if present. We should do this even under error
> * conditions; since the tuplestore would have been using cross-
> * transaction storage, its temp files need to be explicitly deleted.
> */
> if (portal->holdStore)
> {
> MemoryContext oldcontext;
>
> oldcontext = MemoryContextSwitchTo(portal->holdContext);
> tuplestore_end(portal->holdStore);
As far as I can see, there are no caller sites to tuplestore_end in
the abort path or any error handling path.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded
2024-02-21 12:00 BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded PG Bug reporting form <noreply@postgresql.org>
2024-02-22 02:46 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 03:49 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Tender Wang <tndrwang@gmail.com>
2024-02-22 05:38 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 07:00 ` Re: BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded Kyotaro Horiguchi <horikyota.ntt@gmail.com>
@ 2026-05-06 11:26 ` Alex Masterov <amasterov@gmail.com>
0 siblings, 0 replies; 6+ messages in thread
From: Alex Masterov @ 2026-05-06 11:26 UTC (permalink / raw)
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>; +Cc: tndrwang@gmail.com; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Hi,
While running tests with Neon, we discovered an assertion failure that can
occur during re-entrant AbortTransaction() calls.
The issue arises when an error occurs during AbortTransaction() after
ProcArrayEndTransaction() has cleared MyProc->xid. If another error is
raised
during cleanup (e.g., in AtEOXact_Inval()), the PostgresMain error handler
invokes AbortCurrentTransaction() again. The second AbortTransaction() call
reads a still-valid s->transactionId (CleanupTransaction() hasn't run yet)
and passes it to ProcArrayEndTransaction(), which then hits:
Assert(TransactionIdIsValid(proc->xid))
because MyProc->xid was already cleared by the first call.
The attached patch fixes this by checking MyProc->xid validity before
calling
RecordTransactionAbort() and only passing a valid latestXid when
appropriate.
**Reproduction:**
This can be reproduced reliably using the injection_points extension:
1. Attach the injection point:
SELECT injection_points_attach('transaction-end-process-inval', 'error');
2. Create invalidation messages: CREATE TABLE test(id int);
3. Trigger abort: ROLLBACK;
Without the fix: assertion crash on ProcArrayEndTransaction()
With the fix applied: the script will panic with "ERRORDATA_STACK_SIZE
exceeded"
due to re-entrant error handling, demonstrating that the assertion is
resolved.
I've included a reproduction script and the fix that clearly shows both
behaviors.
**Files attached:**
- 0001-xact-Prevent-assertion-failure-in-re-entrant-Abort.patch
- repro_minimal_panic_if_fixed.sh
Thoughts?
Best regards,
Alexey
>
>
>
>
>
>
>
Attachments:
[application/octet-stream] 0001-xact-Prevent-assertion-failure-in-re-entrant-Abort.patch (1.6K, ../../CA+8z=zu-mxXuBtnTVNcOzaGJhgeKSTyeAsK+AdRMr5_XZM1SDw@mail.gmail.com/3-0001-xact-Prevent-assertion-failure-in-re-entrant-Abort.patch)
download | inline diff:
commit d0a862d09016b2c02811821644688cee2c33089d
Author: Alexey Masterov <alexey.masterov@databricks.com>
Date: Wed May 6 11:01:31 2026 +0200
xact: Prevent assertion failure in re-entrant AbortTransaction calls
When an error occurs during AbortTransaction() after ProcArrayEndTransaction()
has cleared MyProc->xid, subsequent abort attempts could pass a valid
latestXid to ProcArrayEndTransaction() while proc->xid is already invalid,
triggering Assert(TransactionIdIsValid(proc->xid)).
Avoid this by checking MyProc->xid validity before calling
RecordTransactionAbort() and only passing a valid latestXid when appropriate.
diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index 48bc90c9673..c7819d7d9d4 100644
--- a/src/backend/access/transam/xact.c
+++ b/src/backend/access/transam/xact.c
@@ -2979,7 +2979,20 @@ AbortTransaction(void)
* record.
*/
if (!is_parallel_worker)
- latestXid = RecordTransactionAbort(false);
+ {
+ /*
+ * Re-entrant abort: if another ERROR is raised during AbortTransaction()
+ * after ProcArrayEndTransaction() cleared our advertised XID, local
+ * transaction state can still report an XID until CleanupTransaction().
+ * Do not run RecordTransactionAbort again (duplicate WAL/clog) and do
+ * not pass a valid latestXid to ProcArrayEndTransaction with proc->xid
+ * already cleared.
+ */
+ if (TransactionIdIsValid(MyProc->xid))
+ latestXid = RecordTransactionAbort(false);
+ else
+ latestXid = InvalidTransactionId;
+ }
else
{
latestXid = InvalidTransactionId;
[text/x-sh] repro_minimal_panic_if_fixed.sh (1.1K, ../../CA+8z=zu-mxXuBtnTVNcOzaGJhgeKSTyeAsK+AdRMr5_XZM1SDw@mail.gmail.com/4-repro_minimal_panic_if_fixed.sh)
download | inline:
#!/usr/bin/env bash
#
# repro_minimal_panic_if_fixed.sh -- Minimal reproduction with raw behavior
#
# This script demonstrates the pure difference between original bug and fixed version:
# • Original bug: TRAP assertion failure (immediate crash)
# • Bug fixed: PANIC ERRORDATA_STACK_SIZE exceeded (infinite loop)
#
# No mitigation, no auto-detach - shows the raw behavior difference.
set -euo pipefail
PSQL=${PSQL:-psql}
echo "⚡ Minimal Re-entrant AbortTransaction Reproduction"
echo "================================================"
echo ""
echo "Expected behavior:"
echo " 🐛 Original bug: TRAP assertion failure"
echo " 🔧 Bug fixed: PANIC ERRORDATA_STACK_SIZE exceeded"
echo ""
$PSQL -c "CREATE EXTENSION IF NOT EXISTS injection_points;" >/dev/null
echo "🧪 Executing minimal reproduction (raw behavior)..."
$PSQL <<'SQL'
SELECT injection_points_set_local();
SELECT injection_points_attach('transaction-end-process-inval', 'error');
BEGIN;
CREATE TABLE _minimal_repro (id int);
ROLLBACK;
SQL
echo "😐 Clean completion - bug conditions not met or injection point didn't fire"
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-05-06 11:26 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-02-21 12:00 BUG #18354: Aborted transaction aborted during cleanup when temp_file_limit exceeded PG Bug reporting form <noreply@postgresql.org>
2024-02-22 02:46 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 03:49 ` Tender Wang <tndrwang@gmail.com>
2024-02-22 05:38 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2024-02-22 07:00 ` Kyotaro Horiguchi <horikyota.ntt@gmail.com>
2026-05-06 11:26 ` Alex Masterov <amasterov@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox