From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Some shared memory chunks are allocated even if related processes won't start |
Date: | 2024-03-04 06:10:45 |
Message-ID: | TYCPR01MB1207795CFE15968D2FD43793BF5232@TYCPR01MB12077.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Tom,
Thanks for replying!
> "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> writes:
> > While reading codes, I found that ApplyLauncherShmemInit() and
> AutoVacuumShmemInit()
> > are always called even if they would not be launched.
> > It may be able to reduce the start time to avoid the unnecessary allocation.
>
> Why would this be a good idea? It would require preventing the
> decision not to launch them from being changed later, except via
> postmaster restart.
Right. It is important to relax their GucContext.
> We've generally been trying to move away
> from unchangeable-without-restart decisions. In your example,
>
> > + if (max_logical_replication_workers == 0 || IsBinaryUpgrade)
> > + return;
>
> max_logical_replication_workers is already PGC_POSTMASTER so there's
> not any immediate loss of flexibility, but I don't think it's a great
> idea to introduce another reason why it has to be PGC_POSTMASTER.
You are right. The first example implied the max_logical_replication_workers
won't be changed. So it is not appropriate.
So ... what about second one? The approach allows to allocate a memory after
startup, which means that users may able to change the parameter from 0 to
natural number in future. (Of course, such an operation is prohibit for now).
Can it be an initial step to ease the condition?
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
https://www.fujitsu.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey M. Borodin | 2024-03-04 06:11:50 | Re: Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block |
Previous Message | Pavel Stehule | 2024-03-04 06:05:15 | Re: Schema variables - new implementation for Postgres 15 |