| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Random pg_upgrade 004_subscription test failure on drongo |
| Date: | 2026-05-16 11:22:03 |
| Message-ID: | 215a085a-7125-45ad-9ec1-c3a13684acd0@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-05-11 Mo 8:10 AM, Andrew Dunstan wrote:
>
> On 2026-05-10 Su 11:00 AM, Alexander Lakhin wrote:
>> Hello Andrew,
>>
>> 13.03.2025 14:19, Andrew Dunstan wrote:
>>>
>>> On 2025-03-13 Th 5:04 AM, vignesh C wrote:
>>>>
>>>> Unfortunately we don't have pg_upgrade_output.d contents in buildfarm
>>>> to see what is the exact reason.
>>>
>>>
>>> That's not supposed to happen. I am testing a fix to see if I can
>>> make it collect the logs, but for now we'll have to wait till the
>>> next failure ..
>>
>> Windows animals still produce mysterious pg_upgrade/004_subscription
>> failures: [1] and [2] (and 006_transfer_modes also failed similarly
>> since
>> then: [3] and [4]). Unluckily, pg_upgrade_output.d/ content is still not
>> shown in the failure logs, so we can only guess why the tests failed. I
>> could not reproduce something alike locally, unfortunately — tried
>> different approaches for several days, but without success, so if we
>> could
>> see the error/failure reason in the log it would be useful, I hope.
>>
>> Regarding 006_transfer_modes, I thought the reason we have no
>> pg_upgrade_output.d/ is that the test removes it explicitly: [5], but I
>> see no clean_node in 004_subscription, so maybe the log collection is
>> yet
>> to be fixed in the buildfarm client.
>>
>> Could you have a look, please?
>>
>> [1]
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2026-05-03%2014%3A03%3A12
>> [2]
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2026-01-12%2000%3A09%3A37
>> [3]
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2025-12-28%2003%3A43%3A24
>> [4]
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2026-01-14%2010%3A52%3A35
>> [5]
>> https://www.postgresql.org/message-id/61d3ce85-9c7b-4eea-bf83-81272cab00c3%40gmail.com
>>
>>
>
> The test looked ok as it was on drongo and fairywren, but I have
> loosened it some more on those to see if we can catch the output logs.
> There are other issues with the 004 test at least (The ok test for the
> output directory is wrong if there's a failure). But that can wait for
> now.
>
>
>
OK, I have found and fixed the buildfarm bug. See
<https://github.com/PGBuildFarm/client-code/commit/55fdf7e0aa355600512a26cdd159b974498f802e>
It will be in the next release, but meanwhile I have deployed it on
drongo and fairywren.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xuneng Zhou | 2026-05-16 11:35:04 | Re: Bound memory usage during manual slot sync retries |
| Previous Message | Zsolt Parragi | 2026-05-16 11:15:34 | Re: [PATCH] Add NESTED_STATEMENTS option to EXPLAIN |