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