Re: Add Pipelining support in psql

From: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add Pipelining support in psql
Date: 2025-01-10 10:59:44
Message-ID: CAO6_Xqq18VZji7G8MMEd8EiuuY1FrsZo=V1ch71aU7uZL6yqjg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I feel there's a large overlap between \flush and \flushrequest. On
> the other hand, if people want to test the behaviour of pushing data
> with and without a flush request message, then \flush can be useful.

I've been looking into some issues related to a backend process stuck
in ClientWrite state blocking the WAL replay and it turns out that
pipelining + \flush was extremely useful to reproduce the issue. It
makes it possible to saturate the server->client socket buffer since
psql doesn't consume the results, easily triggering the state where
the process is stuck in ClientWrite. So I'm amending my position on
the usefulness of \flush and definitely see interesting usages.

I've also found out that I didn't correctly manage connection reset.
I've fixed this in v6 by resetting the pipeline counters on connection
reset and only calling discardAbortedPipelineResults if we're inside a
pipeline.

Attachment Content-Type Size
v06-0001-Add-pipelining-support-in-psql.patch application/octet-stream 54.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2025-01-10 11:05:58 RE: Conflict detection for update_deleted in logical replication
Previous Message David Rowley 2025-01-10 10:37:55 Re: Some ExecSeqScan optimizations