agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedBUG #19551: TRAP: failed Assert("max_pinned_buffers > 0")
4+ messages / 3 participants
[nested] [flat]
* BUG #19551: TRAP: failed Assert("max_pinned_buffers > 0")
@ 2026-07-10 07:36 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 4+ messages in thread
From: PG Bug reporting form @ 2026-07-10 07:36 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: r.zharkov@postgrespro.ru
The following bug has been logged on the website:
Bug reference: 19551
Logged by: Roman Zharkov
Email address: r.zharkov@postgrespro.ru
PostgreSQL version: 17.10
Operating system: WSL2 on Windows 11
Description:
Hello,
This error occurred when attempting run the temp.sql regression test from
the master branch on the REL_17_STABLE (#bab0a2db).
It seems, REL_16_STABLE and REL_18_STABLE work fine.
Trimmed script:
SET temp_buffers = 100;
CREATE TEMPORARY TABLE test_temp(a int not null unique, b TEXT not null, cnt
int not null);
INSERT INTO test_temp SELECT generate_series(1, 10000) as id, repeat('a',
200), 0;
-- should be at least 2x as large than temp_buffers
SELECT pg_relation_size('test_temp') / current_setting('block_size')::int8 >
200;
-- Don't want cursor names and plpgsql function lines in the error messages
\set VERBOSITY terse
/* helper function to create cursors for each page in [p_start, p_end] */
CREATE FUNCTION test_temp_pin(p_start int, p_end int)
RETURNS void
LANGUAGE plpgsql
AS $f$
DECLARE
cursorname text;
query text;
BEGIN
FOR i IN p_start..p_end LOOP
cursorname = 'c_'||i;
query = format($q$DECLARE %I CURSOR FOR SELECT ctid FROM test_temp
WHERE ctid >= '( %s, 1)'::tid $q$, cursorname, i);
EXECUTE query;
EXECUTE 'FETCH NEXT FROM '||cursorname;
-- for test development
-- RAISE NOTICE '%: %', cursorname, query;
END LOOP;
END;
$f$;
-- Test overflow of temp table buffers is handled correctly
BEGIN;
-- should work, below max
SELECT test_temp_pin(0, 9);
-- should fail, too many buffers pinned
SELECT test_temp_pin(10, 105);
ROLLBACK;
Backtrace:
…
#5 0x0000643754e9190c in ExceptionalCondition (conditionName=0x6437550ccf79
"max_pinned_buffers > 0", fileName=0x6437550cccf0
"/home/roman/git/connpool_build/build/../../connpool/src/backend/storage/aio/read_stream.c",
lineNumber=473)
at
/home/roman/git/connpool_build/build/../../connpool/src/backend/utils/error/assert.c:66
#6 0x0000643754c37a4f in read_stream_begin_relation (flags=2, strategy=0x0,
rel=0x7179e34caf78, forknum=MAIN_FORKNUM, callback=0x64375471e46b
<heap_scan_stream_read_next_serial>, callback_private_data=0x6437817b95a8,
per_buffer_data_size=0)
at
/home/roman/git/connpool_build/build/../../connpool/src/backend/storage/aio/read_stream.c:473
#7 0x000064375471f92d in heap_beginscan (relation=0x7179e34caf78,
snapshot=0x64378169b868, nkeys=0, key=0x0, parallel_scan=0x0, flags=272) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/access/heap/heapam.c:1185
#8 0x0000643754a1df61 in table_beginscan_tidrange (rel=0x7179e34caf78,
snapshot=0x64378169b868, mintid=0x6437817b87e0, maxtid=0x6437817b87e6) at
/home/roman/git/connpool_build/build/../../connpool/src/include/access/tableam.h:1097
#9 0x0000643754a1e787 in TidRangeNext (node=0x6437817b86f8) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/nodeTidrangescan.c:243
#10 0x00006437549d23cc in ExecScanFetch (node=0x6437817b86f8,
accessMtd=0x643754a1e6d8 <TidRangeNext>, recheckMtd=0x643754a1e805
<TidRangeRecheck>) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/execScan.c:139
#11 0x00006437549d2471 in ExecScan (node=0x6437817b86f8,
accessMtd=0x643754a1e6d8 <TidRangeNext>, recheckMtd=0x643754a1e805
<TidRangeRecheck>) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/execScan.c:205
#12 0x0000643754a1e8ff in ExecTidRangeScan (pstate=0x6437817b86f8) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/nodeTidrangescan.c:308
#13 0x00006437549cdc93 in ExecProcNodeFirst (node=0x6437817b86f8) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/execProcnode.c:464
#14 0x00006437549c0c12 in ExecProcNode (node=0x6437817b86f8) at
/home/roman/git/connpool_build/build/../../connpool/src/include/executor/executor.h:278
#15 0x00006437549c3b4e in ExecutePlan (queryDesc=0x6437816c3520,
operation=CMD_SELECT, sendTuples=true, numberTuples=1,
direction=ForwardScanDirection, dest=0x6437552bda80 <spi_printtupDR>)
at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/execMain.c:1689
#16 0x00006437549c12dd in standard_ExecutorRun (queryDesc=0x6437816c3520,
direction=ForwardScanDirection, count=1, execute_once=false) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/execMain.c:360
#17 0x00006437549c1136 in ExecutorRun (queryDesc=0x6437816c3520,
direction=ForwardScanDirection, count=1, execute_once=false) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/executor/execMain.c:306
#18 0x0000643754c9b597 in PortalRunSelect (portal=0x6437816c6b78,
forward=true, count=1, dest=0x6437552bda80 <spi_printtupDR>) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/tcop/pquery.c:922
#19 0x0000643754c9c763 in DoPortalRunFetch (portal=0x6437816c6b78,
fdirection=FETCH_FORWARD, count=1, dest=0x6437552bda80 <spi_printtupDR>) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/tcop/pquery.c:1665
#20 0x0000643754c9c0ff in PortalRunFetch (portal=0x6437816c6b78,
fdirection=FETCH_FORWARD, count=1, dest=0x6437552bda80 <spi_printtupDR>) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/tcop/pquery.c:1416
#21 0x0000643754930f24 in PerformPortalFetch (stmt=0x64378153d3f0,
dest=0x6437552bda80 <spi_printtupDR>, qc=0x7ffc60e51fc0) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/commands/portalcmds.c:198
#22 0x0000643754c9d8c9 in standard_ProcessUtility (pstmt=0x64378153d2e0,
queryString=0x643781539a20 "FETCH NEXT FROM c_99", readOnlyTree=true,
context=PROCESS_UTILITY_QUERY, params=0x0, queryEnv=0x0, dest=0x6437552bda80
<spi_printtupDR>,
qc=0x7ffc60e51fc0) at
/home/roman/git/connpool_build/build/../../connpool/src/backend/tcop/utility.c:703
…
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: BUG #19551: TRAP: failed Assert("max_pinned_buffers > 0")
@ 2026-07-13 10:33 Nazir Bilal Yavuz <byavuz81@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 4+ messages in thread
From: Nazir Bilal Yavuz @ 2026-07-13 10:33 UTC (permalink / raw)
To: r.zharkov@postgrespro.ru; pgsql-bugs@lists.postgresql.org
Hi,
On Sat, 11 Jul 2026 at 15:08, PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 19551
> Logged by: Roman Zharkov
> Email address: r.zharkov@postgrespro.ru
> PostgreSQL version: 17.10
> Operating system: WSL2 on Windows 11
> Description:
>
> Hello,
> This error occurred when attempting run the temp.sql regression test from
> the master branch on the REL_17_STABLE (#bab0a2db).
> It seems, REL_16_STABLE and REL_18_STABLE work fine.
Thank you for the reproducer script.
I think this is expected. If you disable asserts, you will see an
actual error message: 'ERROR: no empty local buffer available'. This
error message can be seen on both REL_16_STABLE and REL_18_STABLE too.
--
Regards,
Nazir Bilal Yavuz
Microsoft
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: BUG #19551: TRAP: failed Assert("max_pinned_buffers > 0")
@ 2026-07-13 13:01 Tom Lane <tgl@sss.pgh.pa.us>
parent: Nazir Bilal Yavuz <byavuz81@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2026-07-13 13:01 UTC (permalink / raw)
To: Nazir Bilal Yavuz <byavuz81@gmail.com>; +Cc: r.zharkov@postgrespro.ru, pgsql-bugs@lists.postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Nazir Bilal Yavuz <byavuz81@gmail.com> writes:
> On Sat, 11 Jul 2026 at 15:08, PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> This error occurred when attempting run the temp.sql regression test from
>> the master branch on the REL_17_STABLE (#bab0a2db).
>> It seems, REL_16_STABLE and REL_18_STABLE work fine.
> Thank you for the reproducer script.
> I think this is expected. If you disable asserts, you will see an
> actual error message: 'ERROR: no empty local buffer available'. This
> error message can be seen on both REL_16_STABLE and REL_18_STABLE too.
The point is you're not supposed to be able to trigger an Assert from
SQL. I don't see that Assert in 18 and up, and digging in the git
history shows that 92fc6856c replaced it with some logic including
/*
* The limit might be zero on a system configured with too few buffers for
* the number of connections. We need at least one to make progress.
*/
max_pinned_buffers = Max(1, max_pinned_buffers);
The commit message claims
In practice it was quite difficult to exceed limits and cause any real
problems in v17, so no back-patch for now, but proposed changes will
make it easier.
but evidently "quite difficult" isn't so difficult after all.
I think we must back-patch at least this bit of 92fc6856c.
Thomas, what's your thoughts on how much of that commit to back-patch?
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: BUG #19551: TRAP: failed Assert("max_pinned_buffers > 0")
@ 2026-07-13 13:13 Nazir Bilal Yavuz <byavuz81@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: Nazir Bilal Yavuz @ 2026-07-13 13:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: r.zharkov@postgrespro.ru, pgsql-bugs@lists.postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Hi,
On Mon, 13 Jul 2026 at 16:01, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Nazir Bilal Yavuz <byavuz81@gmail.com> writes:
> > On Sat, 11 Jul 2026 at 15:08, PG Bug reporting form
> > <noreply@postgresql.org> wrote:
> >> This error occurred when attempting run the temp.sql regression test from
> >> the master branch on the REL_17_STABLE (#bab0a2db).
> >> It seems, REL_16_STABLE and REL_18_STABLE work fine.
>
> > Thank you for the reproducer script.
>
> > I think this is expected. If you disable asserts, you will see an
> > actual error message: 'ERROR: no empty local buffer available'. This
> > error message can be seen on both REL_16_STABLE and REL_18_STABLE too.
>
> The point is you're not supposed to be able to trigger an Assert from
> SQL.
I see. Thanks for the clarification.
--
Regards,
Nazir Bilal Yavuz
Microsoft
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-07-13 13:13 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-10 07:36 BUG #19551: TRAP: failed Assert("max_pinned_buffers > 0") PG Bug reporting form <noreply@postgresql.org>
2026-07-13 10:33 ` Nazir Bilal Yavuz <byavuz81@gmail.com>
2026-07-13 13:01 ` Tom Lane <tgl@sss.pgh.pa.us>
2026-07-13 13:13 ` Nazir Bilal Yavuz <byavuz81@gmail.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox