[pgpool-general: 9388] Re: [EXTERNAL] Re: PostgreSQL: 25001: DISCARD ALL cannot be executed within a pipeline

[Tatsuo Ishii]

> Mr. Tatsuo Ishi,
> 
> Thank you for your quick response.
> 
> We see a very clear difference between v4.5.2 and v4.5.4.
> In v4.5.2, queries are consistently failing with the "DISCARD ALL cannot be executed within a pipeline". However, when using v4.5.4, all these errors have disappeared.

I did not expect 4.5.4 does not trigger the pipleline error. Let me
check.

> We use Npgsql v4.0.13 on the Microsoft Data Gateway (Power BI Gateway). Do you happen to know of any issues reported with this version of Npgsql?

Sorry I am not familiar with Npgsql and cannot answer.

Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

> Thank you in advance,
> 
> Martien Truijen
> Fluke Corporation
> Everett, WA USA
> 
> 
> 
> -----Original Message-----
> From: Tatsuo Ishii <ishii at postgresql.org>
> Sent: Wednesday, March 5, 2025 1:04 AM
> To: Truijen, Martien <martien.truijen at fluke.com>
> Cc: pgpool-general at pgpool.net
> Subject: [EXTERNAL] Re: [pgpool-general: 9385] PostgreSQL: 25001: DISCARD ALL cannot be executed within a pipeline
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> 
>> With Pgpool-II 4.5.2, we had a lot of reports from users that reports were failing with "PostgreSQL: 25001: DISCARD ALL cannot be executed within a pipeline" .
>> We upgraded to 4.5.4 with the hope that it would fix the issue. There was no obvious release note that was indicating that it would fix the issue.
>> Luckily version 4.5.4 is no longer throwing this error.
>>
>> My question here is, what specific bug was fixed in 4.5.3 or 4.5.4 that could have fixed  this issue.
>> Any help would be greatly appreciated.
> 
> It's not fixed because it is not a bug of Pgpool-II IMO. Actually it's caused by client's (or driver's) bug. In this case the client initiates an extended query protocol. In the protocol, the client should send "Sync" message at the end of command (thus before exiting the session) but when the error appears the client did not send Sync, which is not a good behavior from the protocol's point of view:
> 
> https://urldefense.com/v3/__https://www.postgresql.org/docs/17/protocol-flow.html*PROTOCOL-FLOW-EXT-QUERY__;Iw!!KPww_GFiJXw!aIKG6j6Vt6iOMwRbb4pKYEIVdgXB5jooOc7OOnGkID1t9SgwGpyhYdvaiwD9hCgcDFUFkBrgV3he6EzyPBGZXw$
> 
> "At completion of each series of extended-query messages, the frontend should issue a Sync message."
> 
> I suggest to fix the client (or driver).
> 
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS K.K.
> English: https://urldefense.com/v3/__http://www.sraoss.co.jp/index_en/__;!!KPww_GFiJXw!aIKG6j6Vt6iOMwRbb4pKYEIVdgXB5jooOc7OOnGkID1t9SgwGpyhYdvaiwD9hCgcDFUFkBrgV3he6Eyw_4ltlw$
> Japanese:https://urldefense.com/v3/__http://www.sraoss.co.jp__;!!KPww_GFiJXw!aIKG6j6Vt6iOMwRbb4pKYEIVdgXB5jooOc7OOnGkID1t9SgwGpyhYdvaiwD9hCgcDFUFkBrgV3he6ExFRJejCA$
> ________________________________
> ________________________________
> 
> 
> Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message.