Re: Introduce "log_connection_stages" setting. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Introduce "log_connection_stages" setting.
Date
Msg-id 2309020.1677797774@sss.pgh.pa.us
Whole thread Raw
In response to Re: Introduce "log_connection_stages" setting.  (Jacob Champion <jchampion@timescale.com>)
Responses Re: Introduce "log_connection_stages" setting.  (Jacob Champion <jchampion@timescale.com>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: buildfarm + meson
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: Memory leak from ExecutorState context?