Using PQexecQuery in pipeline mode produces unexpected Close messages

From: Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>
To: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Using PQexecQuery in pipeline mode produces unexpected Close messages
Date: 2022-06-08 13:59:41
Message-ID: CA+mi_8bvD0_CW3sumgwPvWdNzXY32itoG_16tDYRu_1S2gV2iw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hello,

Experimenting with pipeline mode, with libpq 14.2, sometimes we
receive the notice "message type 0x33 arrived from server while idle".
Tested with Postgres server 12 and 14.

This notice is generated by libpq upon receiving messages after using
PQsendQuery(). The libpq trace shows:

F 101 Parse "" "INSERT INTO pq_pipeline_demo(itemno,
int8filler) VALUES (1, 4611686018427387904) RETURNING id" 0
F 12 Bind "" "" 0 0 0
F 6 Describe P ""
F 9 Execute "" 0
F 6 Close P ""
F 4 Flush
B 4 ParseComplete
B 4 BindComplete
B 27 RowDescription 1 "id" 561056 1 23 4 -1 0
B 11 DataRow 1 1 '3'
B 15 CommandComplete "INSERT 0 1"
B 4 CloseComplete
F 4 Sync
B 5 ReadyForQuery I

in the state the server messages are received, CloseComplete is unexpected.

For comparison, PQsendQueryParams() produces the trace:

F 93 Parse "" "INSERT INTO pq_pipeline_demo(itemno,
int8filler) VALUES ($1, $2) RETURNING id" 2 21 20
F 36 Bind "" "" 2 1 1 2 2 '\x00\x01' 8
'@\x00\x00\x00\x00\x00\x00\x00' 1 0
F 6 Describe P ""
F 9 Execute "" 0
F 4 Flush
B 4 ParseComplete
B 4 BindComplete
B 27 RowDescription 1 "id" 561056 1 23 4 -1 0
B 11 DataRow 1 1 '4'
B 15 CommandComplete "INSERT 0 1"
F 4 Sync
B 5 ReadyForQuery I

where no Close is sent.

Is this a problem with PQexecQuery which should not send the Close, or
with receiving in IDLE mode which should expect a CloseComplete?

Should we avoid using PQexecQuery in pipeline mode altogether?

A playground to reproduce the issue is available at
https://github.com/psycopg/psycopg/issues/314

Cheers

-- Daniele

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-06-08 14:05:59 Re: Fallout from 'Make type "name" collation-aware' and tg_table_name
Previous Message Christoph Berg 2022-06-08 13:07:57 Fallout from 'Make type "name" collation-aware' and tg_table_name

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2022-06-08 14:15:17 RE: pgcon unconference / impact of block size on performance
Previous Message Pavel Stehule 2022-06-08 13:17:50 Re: => operator for named parameters in open cursor