[PATCH] Fix two client-side NULL dereferences on malformed result sets (libpq, pg_receivewal)

Hi,

Two client programs crash when the server answers an internal query with a
result set of an unexpected shape. Both are plain NULL dereferences: the
code
checks part of the shape, then calls PQgetvalue() on a cell that does not
exist. (First sent to security@, Noah pointed me here since the project does
not treat these as security issues.)

0001 - libpq, fe-connect.c. PQconnectPoll gates the target_session_attrs
probes ("SHOW transaction_read_only" and "SELECT pg_is_in_recovery()") on
PQntuples(res) == 1 but never on PQnfields(res), then does
strncmp(PQgetvalue(res, 0, 0), ...). One row and zero columns gives
strncmp(NULL, ...). The patch requires PQnfields(res) == 1 too, so a bad
reply
takes the existing "Something went wrong" error path and the connection
attempt fails.

0002 - pg_basebackup, receivelog.c. The TIMELINE_HISTORY shape check logs a
warning and falls through to writeTimeLineHistoryFile(PQgetvalue(res, 0, 0),
PQgetvalue(res, 0, 1)), which calls strlen() on the NULL right away. The
patch
makes the check fatal (pg_log_error, PQclear, return false), matching the
other error returns in that block. It has been like this since cc8d4151172.

Tested on master at 0607aa6109 with clang 21 and
-fsanitize=address,undefined
against a small fake server on loopback: both crash before the patch, both
report a clean error after it, and the well-formed control paths still work
(libpq connects, pg_receivewal writes the history file and moves on to
START_REPLICATION). Both fixes apply cleanly to the back branches as far as
I checked, but I have only run them on master.

Regards,
s1ko