Horton

Re: BackendKeyData is mandatory?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, Jacob Champion <jacob.champion@enterprisedb.com>, Tatsuo Ishii <ishii@postgresql.org>, peter@eisentraut.org, pgsql-hackers@postgresql.org, Dave Cramer <davecramer@gmail.com>
Date: 2025-08-08T14:01:05Z
Lists: pgsql-hackers 
Heikki Linnakangas <hlinnaka@iki.fi> writes:
> I noticed that there's a similar, existing case in getNotify(), where 
> libpq just hangs if an allocation fails. To simulate that, apply this 
> change and use LISTEN/NOTIFY:

> --- a/src/interfaces/libpq/fe-protocol3.c
> +++ b/src/interfaces/libpq/fe-protocol3.c
> @@ -1587,7 +1587,7 @@ getNotify(PGconn *conn)
>   	if (pqGets(&conn->workBuffer, conn))
>   		return EOF;
>   	/* must save name while getting extra string */
> -	svname = strdup(conn->workBuffer.data);
> +	svname = NULL;
>   	if (!svname)
>   		return EOF;
>   	if (pqGets(&conn->workBuffer, conn))

> Returning EOF means "not enough data", which is wrong here just like in 
> getBackendKeyData().

The implication of "return EOF" is "try again later", which seems like
about the best thing we can do.  If memory serves, other places that
construct query results do likewise.

			regards, tom lane

Commits

  1. Revert unnecessary check for NULL

  2. libpq: Be strict about cancel key lengths

  3. libpq: Handle OOM by disconnecting instead of hanging or skipping msgs

  4. libpq: Complain about missing BackendKeyData later with PGgetCancel()