From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Assertion failure in pgbench |
Date: | 2025-07-30 15:51:58 |
Message-ID: | CAHGQGwFAX56Tfx+1ppo431OSWiLLuW72HaGzZ39NkLkop6bMzQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I encountered the following assertion failure in pgbench on the current master:
Assertion failed: (res == ((void*)0)), function discardUntilSync,
file pgbench.c, line 3515.
Abort trap: 6
This can be reliably reproduced with the following steps:
------------------------
$ psql -c "ALTER SYSTEM SET default_transaction_isolation TO 'serializable'"
$ psql -c "SELECT pg_reload_conf()"
$ pgbench -i
$ cat test.sql
\set aid random(1, 100000 * :scale)
\set bid random(1, 1 * :scale)
\set tid random(1, 10 * :scale)
\set delta random(-5000, 5000)
\startpipeline
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES
(:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
\endpipeline
$ pgbench -f test.sql -c 10 -j 10 -T 60 -M extended
------------------------
Even without a custom script, shutting down the server with
immediate mode while running "pgbench -c 10 -j 10 -T 60" could
trigger the same assertion, though not always reliably.
/* receive PGRES_PIPELINE_SYNC and null following it */
for (;;)
{
PGresult *res = PQgetResult(st->con);
if (PQresultStatus(res) == PGRES_PIPELINE_SYNC)
{
PQclear(res);
res = PQgetResult(st->con);
Assert(res == NULL);
break;
}
PQclear(res);
}
The failure occurs in this code. This code assumes that PGRES_PIPELINE_SYNC
is always followed by a NULL. However, it seems that another
PGRES_PIPELINE_SYNC can appear consecutively, which violates that assumption
and causes the assertion to fail. Thought?
Regards.
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-07-30 15:52:03 | Re: teach pg_upgrade to handle in-place tablespaces |
Previous Message | Tom Lane | 2025-07-30 15:48:08 | Re: Making type Datum be 8 bytes everywhere |