| From: | Tomas Vondra <tomas(at)vondra(dot)me> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Bernd Helmle <mailings(at)oopsware(dot)de>, Michael Banck <mbanck(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Changing the state of data checksums in a running cluster |
| Date: | 2026-08-24 09:38:07 |
| Message-ID: | 2bcd05e4-c98c-4b0e-a561-90e75a60206c@vondra.me |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/24/26 03:25, Michael Paquier wrote:
> On Sun, Aug 23, 2026 at 07:30:32PM +0200, Tomas Vondra wrote:
>> I'm 99% sure this is a configuration issue in the test, not a bug in the
>> online checksums code. It happens because with
>>
>> debug_parallel_query = regress
>
> Is the coverage provided by debug_parallel_query useful to have in
> this context?
>
>> queries start enough parallel workers to exhaust max_worker_processes,
>> and so we fail to start the checksum worker.
>>
>> I've modified the TAP tests to add
>>
>> max_worker_processes = 16
>> max_parallel_workers = 16
>>
>> and with that change it passes just fine.
>
> One option would be debug_parallel_query = off to shave the number of
> workers spawned.
Yeah. I don't think "debug_parallel_query = regress" is not very helpful
or this test, 99% of the code is in the background worker anyway.
regards
--
Tomas Vondra
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Sharma | 2026-08-24 09:45:11 | Re: Report bytes and transactions actually sent downtream |
| Previous Message | Daniel Gustafsson | 2026-08-24 09:32:25 | Re: Add explicit warnings about unsafe OAuth trace output for libpq |