Thread: Re: BUG #18944: Assertion Failure in psql with idle_session_timeout Set

On Mon, Jun 02, 2025 at 07:00:26PM +0200, Anthonin Bonnefoy wrote:
> So if that's expected, we may need additional logic to avoid
> increasing piped_syncs when we're after a COPY? On the other hand,
> ignoring the SYNC seems to break the protocol spec expectation that
> "there is one and only one ReadyForQuery sent for each Sync".

Hmm.  This stuff stands as it is in the backend COPY code since
c01641f8aed0 from 2003, so there's not much we can do in the backend
or libpq.  Adding some specific logic in psql to avoid piped_syncs
seems like the correct move seen from here.

Most of that should be close to ExecQueryAndProcessResults(), don't
you think?  That's where we count the number of piped syncs.
--
Michael

On Tue, Jun 3, 2025 at 1:31 AM Michael Paquier <michael@paquier.xyz> wrote:
> Hmm.  This stuff stands as it is in the backend COPY code since
> c01641f8aed0 from 2003, so there's not much we can do in the backend
> or libpq.  Adding some specific logic in psql to avoid piped_syncs
> seems like the correct move seen from here.
>
> Most of that should be close to ExecQueryAndProcessResults(), don't
> you think?  That's where we count the number of piped syncs.

I've tried to adjust the piped syncs counter, but that's not enough.
libpq's internal command queue still has the Syncs queued and will
stay in a busy pipeline state if the backend doesn't send the expected
ReadyForQuery. It could be possible to remove them from the queue with
pqCommandQueueAdvance, but that would require psql to include
libpq-int.h which is probably something we want to avoid.

It doesn't seem like this case can be handled gracefully. The provided
patch just aborts the connection from the frontend when excessive
piped syncs are detected to avoid staying stuck in this inconsistent
protocol state.