| From: | Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Disable bgworkers during servers start in pg_upgrade |
| Date: | 2021-08-26 07:15:25 |
| Message-ID: | 7d470953-07cb-f9dc-f7b3-d33697644b54@dalibo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier a écrit :
>> @@ -5862,6 +5862,9 @@ do_start_bgworker(RegisteredBgWorker *rw)
>> static bool
>> bgworker_should_start_now(BgWorkerStartTime start_time)
>> {
>> + if (IsBinaryUpgrade)
>> + return false;
>> +
> Using -c max_worker_processes=0 would just have the same effect, no?
> So we could just patch pg_upgrade's server.c to get the same level of
> protection?
Yes, same effect indeed. This would log "too many background workers"
messages in pg_upgrade logs, though.
See attached patch implementing this suggestion.
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Disable-bgworkers-at-servers-start-in-pg_upgrade.patch | text/x-patch | 1.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Denis Smirnov | 2021-08-26 07:21:04 | Re: Async-unsafe functions in signal handlers |
| Previous Message | Amit Kapila | 2021-08-26 06:30:23 | Re: Skipping logical replication transactions on subscriber side |