Re: fairywren timeout failures on the pg_amcheck/005_opclass_damage test

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fairywren timeout failures on the pg_amcheck/005_opclass_damage test
Date: 2024-07-26 13:00:00
Message-ID: c903eaab-e4a3-9504-939d-a8e17e09948c@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

26.07.2024 15:41, Andrew Dunstan wrote:
>
>>
>> One way to workaround this is to disable debug_parallel_query in the test
>> and another I find possible is to set max_parallel_workers = 0.
>>
>>
>
> But wouldn't either of those just be masking the problem?
>

Yes, I'm inclined to consider this behavior a problem (what if the table
contained 1M rows?), that's why I called those solutions workarounds.

Of course, there are parallel_setup_cost and parallel_tuple_cost
parameters, which can prevent this from happening in the wild, but still...

Best regards.
Alexander

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcos Pegoraro 2024-07-26 13:00:33 Re: Detailed release notes
Previous Message Marina Polyakova 2024-07-26 12:47:01 Re: tls 1.3: sending multiple tickets