Assertion failure in pgbench

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

Responses

Browse pgsql-hackers by date

  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