Re: Refine comments on usage WL_POSTMASTER_DEATH vs WL_EXIT_ON_PM_DEATH
От | Heikki Linnakangas |
---|---|
Тема | Re: Refine comments on usage WL_POSTMASTER_DEATH vs WL_EXIT_ON_PM_DEATH |
Дата | |
Msg-id | c2c1631f-79ef-4ec3-9a8b-212118d5ee22@iki.fi обсуждение исходный текст |
Ответ на | Re: Refine comments on usage WL_POSTMASTER_DEATH vs WL_EXIT_ON_PM_DEATH (Pavel Borisov <pashkin.elfe@gmail.com>) |
Ответы |
Re: Refine comments on usage WL_POSTMASTER_DEATH vs WL_EXIT_ON_PM_DEATH
|
Список | pgsql-hackers |
On 23/10/2024 20:29, Pavel Borisov wrote: > Hi, Heikki! > > > > On Wed, 23 Oct 2024 at 21:00, Heikki Linnakangas <hlinnaka@iki.fi > <mailto:hlinnaka@iki.fi>> wrote: > > On 23/10/2024 12:18, Pavel Borisov wrote: > > Hi, Hackers! > > > > Current comments on the usage of WL_POSTMASTER_DEATH state that it > > should be used for scenarios of finishing other than immediately > i.e. > > returning values and waiting for postmaster dies. > > In fact, in parts of the code, it's currently used to immediately > exit > > or throw FATAL (in the walsender and in libpq). > > > > So I propose change the comments on WL_POSTMASTER_DEATH stating > that it > > could be used for both cases: for processing and setting return > values > > if that's needed, and for immediate exit otherwise. > > I see what you mean, but I don't think the proposed patch is making it > better. With WL_POSTMASTER_DEATH, the WaitLatch call returns if the > postmaster dies. What the caller does then is the caller's business. > That's different from WL_EXIT_ON_PM_DEATH in that with > WL_EXIT_ON_PM_DEATH, WaitLatch itself will do the exit(), not the > caller. > > That was exactly my point. Actually the caller should not wait, it could > do whatever it wants contrary to the existing comments: > > WL_POSTMASTER_DEATH: Wait for postmaster to die > > I don't insist on this patch, but existing comments on this look > somewhat misleading. Ok I seem to totally not understand what the problem is then. The comment seems fine to me. ¯\_(ツ)_/¯ -- Heikki Linnakangas Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: