Content-Type: multipart/alternative;
 boundary="------------P1Tt1vfzYPTg9sti9cfX9GHZ"
Message-ID: <f7cfb56d-c7d6-40d9-b08d-ee5232f95cba@gmail.com>
Date: Fri, 29 May 2026 07:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19494: Error on transaction commit inside pipeline triggers
 psql's Assert
To: Michael Paquier <michael@paquier.xyz>, pgsql-bugs@lists.postgresql.org
References: <19494-97a86d84fee71c47@postgresql.org>
 <ahe7ylLcESTmnZfk@paquier.xyz> <ahfR7s1ZXC6MSC0i@paquier.xyz>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <ahfR7s1ZXC6MSC0i@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/f7cfb56d-c7d6-40d9-b08d-ee5232f95cba%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------P1Tt1vfzYPTg9sti9cfX9GHZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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
--------------P1Tt1vfzYPTg9sti9cfX9GHZ
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Michael,<br>
      <br>
      28.05.2026 08:26, Michael Paquier wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:ahfR7s1ZXC6MSC0i@paquier.xyz">
      <pre wrap="" class="moz-quote-pre">On Thu, May 28, 2026 at 12:51:38PM +0900, Michael Paquier wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">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.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
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?
</pre>
    </blockquote>
    <br>
    While testing the patch, I've observed apparently new anomaly. psql
    got<br>
    stuck inside this loop:<br>
        if (end_pipeline)<br>
        {<br>
            /*<br>
             * Reset available/requested results.  Normally these are
    already 0,<br>
             * but an error generated by Sync processing itself can
    leave some of<br>
             * them behind.  Consume them before exiting pipeline mode.<br>
             */<br>
            while (pset.piped_syncs &gt; 0)<br>
            {<br>
                PGresult   *remaining = PQgetResult(pset.db);<br>
    <br>
                if (remaining == NULL)<br>
                    continue;<br>
    ...<br>
            }<br>
    <br>
    it's happening upon/after postgres process termination, so
    PQgetResult()<br>
    returns NULL, pset.piped_syncs == 1. I need more time to look deeper
    and<br>
    to come with a reproducer, but maybe you can already see what's
    wrong.<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------P1Tt1vfzYPTg9sti9cfX9GHZ--