Re: Introduce "log_connection_stages" setting.
От | Tom Lane |
---|---|
Тема | Re: Introduce "log_connection_stages" setting. |
Дата | |
Msg-id | 2309020.1677797774@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Introduce "log_connection_stages" setting. (Jacob Champion <jchampion@timescale.com>) |
Ответы |
Re: Introduce "log_connection_stages" setting.
|
Список | pgsql-hackers |
Jacob Champion <jchampion@timescale.com> writes: > This is looking very good. One bigger comment: >> + myextra = (int *) guc_malloc(ERROR, sizeof(int)); >> + *myextra = newlogconnect; > If I've understood Tom correctly in [1], both of these guc_mallocs > should be using a loglevel less than ERROR, to avoid forcing a > postmaster exit when out of memory. (I used WARNING in that thread > instead, which seemed to be acceptable.) Actually, preferred practice is as seen in e.g. check_datestyle: myextra = (int *) guc_malloc(LOG, 2 * sizeof(int)); if (!myextra) return false; myextra[0] = newDateStyle; myextra[1] = newDateOrder; *extra = (void *) myextra; which gives the guc.c functions an opportunity to manage the failure. A quick grep shows that there are existing check functions that did not get that memo, e.g. check_recovery_target_lsn. We ought to clean them up. This is, of course, not super important unless you're allocating something quite large; the odds of going OOM in the postmaster should be pretty small. regards, tom lane
В списке pgsql-hackers по дате отправления: