RE: Some shared memory chunks are allocated even if related processes won't start
От | Hayato Kuroda (Fujitsu) |
---|---|
Тема | RE: Some shared memory chunks are allocated even if related processes won't start |
Дата | |
Msg-id | TYCPR01MB1207795CFE15968D2FD43793BF5232@TYCPR01MB12077.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Some shared memory chunks are allocated even if related processes won't start (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Dear Tom, Thanks for replying! > "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.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/
В списке pgsql-hackers по дате отправления: