Horton

Re: BackendKeyData is mandatory?

Jelte Fennema-Nio <postgres@jeltef.nl>

View thread View on postgr.es
From: "Jelte Fennema-Nio" <postgres@jeltef.nl>
To: "Jacob Champion" <jacob.champion@enterprisedb.com>
Cc: "Tatsuo Ishii" <ishii@postgresql.org>, <tgl@sss.pgh.pa.us>, <hlinnaka@iki.fi>, <peter@eisentraut.org>, <pgsql-hackers@postgresql.org>, "Dave Cramer" <davecramer@gmail.com>
Date: 2025-07-03T06:13:10Z
Lists: pgsql-hackers

Attachments

On Thu Jul 3, 2025 at 2:03 AM CEST, Jacob Champion wrote:
> On Wed, Jul 2, 2025 at 3:18 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I will hold off on detailed review until Heikki gives an opinion on
> the design (or we get closer to the end of the month), to avoid making
> busy work for you -- but I will say that I think you need to prove
> that the new `failure:` case in getBackendKeyData() is safe, because I
> don't think any of the other failure modes behave that way inside
> pqParseInput3().

I changed it slightly now to align with the handleSyncLoss function its
implementation.

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()