> On Nov 13, 2025, at 13:50, Yugo Nagata <[email protected]> wrote:
>
>
> To trigger a deadlock error, the tables need to have enough rows so that the
> scan takes some
> time. In my environment, about 1,000 rows were enough to cause a deadlock.
>
Yes, after inserting 1000 rows, I got the assert triggered. I added some logs
to track what had been read:
```
% pgbench -n --failures-detailed -M extended -j 2 -c 2 -f deadlock.sql -f
deadlock2.sql evantest
pgbench (19devel)
EVAN: on error discard: Got result: res=11, conn=0
EVAN: on error discard: Got result: res=7, conn=0
EVAN: discardUntilSync: Got result: res=10, conn=0 <== received sync
EVAN: discardUntilSync: Got sync, conn=0
EVAN: discardUntilSync: Got result: res=2, conn=0 <== then immediately received
result of next select, without a null res in between
EVAN: discardUntilSync: Got result value: 2, conn=0
Assertion failed: (res == ((void*)0)), function discardUntilSync, file
pgbench.c, line 3579.
zsh: abort pgbench -n --failures-detailed -M extended -j 2 -c 2 -f
deadlock.sql -f
```
Looks like there is not a null result following the PIPELINE_SYNC message.
So the code comment seems to not accurate:
```
/*
* PGRES_PIPELINE_SYNC must be followed by another
* PGRES_PIPELINE_SYNC or NULL; otherwise, assert failure.
*/
Assert(res == NULL);
```
Then I made a dirty change that return from discardUntilSync() once receives
SYNC:
```
if (PQresultStatus(res) == PGRES_PIPELINE_SYNC)
{
printf("EVAN: discardUntilSync: Got sync, conn=%d\n",
PQstatus(st->con));
received_sync = true;
st->num_syncs = 0;
PQclear(res);
break;
}
```
that eliminates the assert:
```
% pgbench -n --failures-detailed -M extended -j 2 -c 2 -f deadlock.sql -f
deadlock2.sql evantest
pgbench (19devel)
EVAN: on error discard: Got result: res=11, conn=0
EVAN: on error discard: Got result: res=7, conn=0
EVAN: discardUntilSync: Got result: res=10, conn=0
EVAN: discardUntilSync: Got sync, conn=0
pgbench: error: client 0 aborted: failed to exit pipeline mode for rolling back
the failed transaction
transaction type: multiple scripts
scaling factor: 1
query mode: extended
number of clients: 2
number of threads: 2
maximum number of tries: 1
number of transactions per client: 10
number of transactions actually processed: 10/20
number of failed transactions: 0 (0.000%)
number of serialization failures: 0 (0.000%)
number of deadlock failures: 0 (0.000%)
latency average = 203.933 ms
initial connection time = 3.006 ms
tps = 9.807152 (without initial connection time)
SQL script 1: deadlock.sql
- weight: 1 (targets 50.0% of total)
- 8 transactions (80.0% of total)
- number of transactions actually processed: 8 (tps = 7.845722)
- number of failed transactions: 0 (0.000%)
- number of serialization failures: 0 (0.000%)
- number of deadlock failures: 0 (0.000%)
- latency average = 127.115 ms
- latency stddev = 332.002 ms
SQL script 2: deadlock2.sql
- weight: 1 (targets 50.0% of total)
- 2 transactions (20.0% of total)
- number of transactions actually processed: 2 (tps = 1.961430)
- number of failed transactions: 0 (0.000%)
- number of serialization failures: 0 (0.000%)
- number of deadlock failures: 0 (0.000%)
- latency average = 1.347 ms
- latency stddev = 0.207 ms
pgbench: error: Run was aborted; the above results are incomplete.
```
So, I think now the key problem is to confirm if there must be a NULL following
PGRES_PIPELINE_SYNC.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
