Re: BackendKeyData is mandatory?

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org, Dave Cramer <davecramer(at)gmail(dot)com>
Subject: Re: BackendKeyData is mandatory?
Date: 2025-08-22 11:56:35
Message-ID: 2da9038e-bf17-47d1-a5aa-83277c23f3fa@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 19/08/2025 23:49, Jelte Fennema-Nio wrote:
> On Thu, 14 Aug 2025 at 15:10, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> Here's a new set of patches, to disconnect on OOM instead of hanging or
>> silently discarding messages:
>
> Code looks good. Som small nitpicks though.
>
> This change seems unnecessary, i.e. free(NULL) is a no-op
>
> - free(svname);
> + if (svname)
> + free(svname);

And even more so, this is unreachable when svname == NULL. Thanks!

> Small wording suggestion, maybe change this:
>
> The caller has already saved the error message in conn->errorMessage.
>
> to
>
> The caller should have already saved the error message in conn->errorMessage.
>
> or even
>
> The caller should have already saved the error message using
> libpq_append_conn_error.

I kept it as is, because we use similar wording in a few other places.
Some places do write the message directly in conn->errorMessage without
using libpq_append_conn_error.

Pushed and backpatched to v18. I feel the OOM handling commit would be
appropriate to backpatch further, but since it's pretty intricate code
and we haven't gotten any complaints from the field, I only backpatched
it to v18 for now. We can backpatch it further later if needed.

Thanks for the original patch and the review!

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2025-08-22 12:18:06 Re: Improve cache hit rate for OprCacheHash
Previous Message Andrei Lepikhov 2025-08-22 11:53:26 Re: Let plan_cache_mode to be a little less strict