| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: wake up logical workers after ALTER SUBSCRIPTION |
| Date: | 2022-12-14 19:02:58 |
| Message-ID: | 2787771.1671044578@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> On Wed, Dec 14, 2022 at 01:23:18PM -0500, Tom Lane wrote:
>> Oh. What in the world is the rationale for that?
> My assumption is that this is meant to avoid starting workers as fast as
> possible if they repeatedly crash.
I can see the point of rate-limiting if the workers are failing to connect
or crashing while trying to process data. But it's not very sane to
apply the same policy to an intentional worker exit-for-reconfiguration.
Maybe we could have workers that are exiting for that reason set a
flag saying "please restart me without delay"?
A *real* fix would be to not exit at all, at least for reconfigurations
that don't change the connection parameters, but instead cope with
recomputing whatever needs recomputed in the workers' state. I can
believe that that'd be a lot of work though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2022-12-14 19:05:13 | Re: allow granting CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX |
| Previous Message | Jonathan S. Katz | 2022-12-14 18:59:04 | Re: Raising the SCRAM iteration count |