Re: BUG #19494: Error on transaction commit inside pipeline triggers psql's Assert

Hello Michael,

28.05.2026 08:26, Michael Paquier wrote:
> On Thu, May 28, 2026 at 12:51:38PM +0900, Michael Paquier wrote:
>> I am completely sure yet, but it looks like we will need to be smarter
>> with the handling of the number of piped commands by tracking them
>> across the syncs in the shape of a queue, or something like that? So
>> it feels like we need to think harder about the tracking of this
>> activity depending on the state of the pipeline we're in. Or we could
>> lift some of these assertions, but that would not be right to me.
> Hmm. Taking a step back this would be overcomplicating things. As
> long as we are careful to consume the synced results still in a
> pipeline, it looks like we should be fine. While digging into it, I
> have found a third assertion that was triggerable with
> available_results at the end of the pipeline, once I began mixing
> \getresults with a deferred error.
>
> This stuff is tricky enough that I may not have overseen all the
> patterns possible, of course, at least this is progress.
>
> Alexander, what do you think?

While testing the patch, I've observed apparently new anomaly. psql got
stuck inside this loop:
    if (end_pipeline)
    {
        /*
         * Reset available/requested results.  Normally these are already 0,
         * but an error generated by Sync processing itself can leave some of
         * them behind.  Consume them before exiting pipeline mode.
         */
        while (pset.piped_syncs > 0)
        {
            PGresult   *remaining = PQgetResult(pset.db);

            if (remaining == NULL)
                continue;
...
        }

it's happening upon/after postgres process termination, so PQgetResult()
returns NULL, pset.piped_syncs == 1. I need more time to look deeper and
to come with a reproducer, but maybe you can already see what's wrong.

Best regards,
Alexander