Content-Type: multipart/alternative;
 boundary="------------38tmIkkBFXuciBH3mIIC5Iy5"
Message-ID: <67e69649-30ff-4b72-9427-7978010701af@gmail.com>
Date: Mon, 28 Apr 2025 21:00:01 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: optimize file transfer in pg_upgrade
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
 Andres Freund <andres@anarazel.de>, Greg Sabino Mullane
 <htamfids@gmail.com>, pgsql-hackers@postgresql.org, bruce@momjian.us
References: <7rhxl5nl5cuenm4kzprjhaojo74m2teuwzjffcrdi6bxx6b2wn@orb5h3mteh2y>
 <Z9nEup6k56N_9l0X@nathan> <Z9oofphRMQQzgRmL@nathan> <Z9rjSmA_MpPz-zOw@nathan>
 <712605.1742401713@sss.pgh.pa.us>
 <can7m7lntp3rpwchr7upnlom4fhzwfwttfa53xks2yxxafxfkv@3nzrihnqmx4g>
 <Z9sbsU4cu7O9glEQ@nathan> <Z9s29-mO6wnSEU_r@nathan> <Z9t3QsiVz2jHw76A@nathan>
 <7161562f-d00d-41a6-bd8a-d15684d3eaf2@gmail.com> <aA-beRzxOK-GhvaD@nathan>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <aA-beRzxOK-GhvaD@nathan>
Archived-At: <https://www.postgresql.org/message-id/67e69649-30ff-4b72-9427-7978010701af%40gmail.com>
Precedence: bulk

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

Hello Nathan,

28.04.2025 18:15, Nathan Bossart wrote:
> I see a couple of other pg_upgrade failures on drongo and fairywren that
> look similar, although these are for different tests:
>
> 	https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2025-03-10%2019%3A26%3A35
> 	https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2025-03-30%2013%3A03%3A05

Yeah, I've categorized the first one as [1], but now I see that it's
something different, because "pg_upgrade_output.d/ removed after
successful pg_upgrade" is not the only (and not the first) failure there.
Will fix. As to the second one, yes, it's similar in the sense that the
failed test log doesn't contain information needed to understand the
cause.

>> Moreover, even when pg_upgrade succeeds, IPC::Run::run inside
>> command_ok_or_fails_like() returns false, as we can see from a
>> successful test run:
>> https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=fairywren&dt=2025-04-27%2001%3A03%3A06&stg=misc-check
>>
>> pgsql.build/testrun/pg_upgrade/006_transfer_modes/log/regress_log_006_transfer_modes
>> [01:18:38.210](21.036s) ok 1 - pg_upgrade with transfer mode --clone: stdout matches
>> [01:18:38.211](0.001s) ok 2 - pg_upgrade with transfer mode --clone: stderr matches
> That's expected for platforms that don't support all of the modes.  We
> verify the output matches a known error message in that case.

Yes, I meant that in that case we can't determine whether to preserve logs
of the failed pg_upgrade outside of command_ok_or_fails_like().

>> So maybe it's worth to adjust the test somehow to have interesting logs
>> left after a failure?
> I see some other discussion about failures with similar symptoms [0] [1].
> Commit 6f97ef0 seems to have helped with one of the tests, and there is a
> proposed patch in the latest thread [2] that AFAICT aims to fix the
> underlying issue.

Thank you for the references! Unfortunately I still can't see where the
lack of upgrade log files is discussed.

In other words, if we had logs like in the case [2], it could be helpful.

[1] 
https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#Upgrade_tests_fail_on_Windows_due_to_pg_upgrade_output.d.2F_not_removed
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&dt=2025-02-20%2017%3A01%3A23

Best regards,
Alexander Lakhin
Neon (https://neon.tech)
--------------38tmIkkBFXuciBH3mIIC5Iy5
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 Nathan,<br>
      <br>
      28.04.2025 18:15, Nathan Bossart wrote:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite" cite="mid:aA-beRzxOK-GhvaD@nathan">
      <pre wrap="" class="moz-quote-pre">I see a couple of other pg_upgrade failures on drongo and fairywren that
look similar, although these are for different tests:

	<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&amp;dt=2025-03-10%2019%3A26%3A35">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&amp;dt=2025-03-10%2019%3A26%3A35</a>
	<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&amp;dt=2025-03-30%2013%3A03%3A05">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&amp;dt=2025-03-30%2013%3A03%3A05</a>
</pre>
    </blockquote>
    <br>
    Yeah, I've categorized the first one as [1], but now I see that it's<br>
    something different, because "pg_upgrade_output.d/ removed after<br>
    successful pg_upgrade" is not the only (and not the first) failure
    there.<br>
    Will fix. As to the second one, yes, it's similar in the sense that
    the<br>
    failed test log doesn't contain information needed to understand the<br>
    cause.<br>
    <br>
    <blockquote type="cite" cite="mid:aA-beRzxOK-GhvaD@nathan">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">Moreover, even when pg_upgrade succeeds, IPC::Run::run inside
command_ok_or_fails_like() returns false, as we can see from a
successful test run:
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=fairywren&amp;dt=2025-04-27%2001%3A03%3A06&amp;stg=misc-check">https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=fairywren&amp;dt=2025-04-27%2001%3A03%3A06&amp;stg=misc-check</a>

pgsql.build/testrun/pg_upgrade/006_transfer_modes/log/regress_log_006_transfer_modes
[01:18:38.210](21.036s) ok 1 - pg_upgrade with transfer mode --clone: stdout matches
[01:18:38.211](0.001s) ok 2 - pg_upgrade with transfer mode --clone: stderr matches
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
That's expected for platforms that don't support all of the modes.  We
verify the output matches a known error message in that case.</pre>
    </blockquote>
    <br>
    Yes, I meant that in that case we can't determine whether to
    preserve logs<br>
    of the failed pg_upgrade outside of command_ok_or_fails_like().<br>
    <br>
    <blockquote type="cite" cite="mid:aA-beRzxOK-GhvaD@nathan">
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">So maybe it's worth to adjust the test somehow to have interesting logs
left after a failure?
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I see some other discussion about failures with similar symptoms [0] [1].
Commit 6f97ef0 seems to have helped with one of the tests, and there is a
proposed patch in the latest thread [2] that AFAICT aims to fix the
underlying issue.</pre>
    </blockquote>
    <br>
    Thank you for the references! Unfortunately I still can't see where
    the<br>
    lack of upgrade log files is discussed.<br>
    <br>
    In other words, if we had logs like in the case [2], it could be
    helpful.<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#Upgrade_tests_fail_on_Windows_due_to_pg_upgrade_output.d.2F_not_removed">https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#Upgrade_tests_fail_on_Windows_due_to_pg_upgrade_output.d.2F_not_removed</a><br>
    [2]
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&amp;dt=2025-02-20%2017%3A01%3A23">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=copperhead&amp;dt=2025-02-20%2017%3A01%3A23</a><br>
    <br>
    Best regards,<br>
    Alexander Lakhin
    <br>
    Neon (<a class="moz-txt-link-freetext" href="https://neon.tech">https://neon.tech</a>)
  </body>
</html>

--------------38tmIkkBFXuciBH3mIIC5Iy5--