Re: libpq copy error handling busted

On Thu, Jun 4, 2020 at 5:37 AM Thomas Munro <thomas.munro@gmail.com> wrote:

> On Thu, Jun 4, 2020 at 1:53 PM Thomas Munro <thomas.munro@gmail.com>
> wrote:
> > On Thu, Jun 4, 2020 at 1:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > Ah, it's better if I put the pqReadData call into *both* the paths
> > > where 1f39a1c06 made pqSendSome give up.  The attached patch seems
> > > to fix the issue for the "pgbench -i" scenario, with either fast-
> > > or immediate-mode server stop.  I tried it with and without SSL too,
> > > just to see.  Still, it's not clear to me whether this might worsen
> > > any of the situations we discussed in the lead-up to 1f39a1c06 [1].
> > > Thomas, are you in a position to redo any of that testing?
>
> It seems to be behave correctly in that scenario.
>
> Here's what I tested.  First, I put this into pgdata/postgresql.conf:
>
> ssl=on
> ssl_ca_file='root+client_ca.crt'
> ssl_cert_file='server-cn-only.crt'
> ssl_key_file='server-cn-only.key'
> ssl_crl_file='root+client.crl'
> ssl_min_protocol_version='TLSv1.2'
> ssl_max_protocol_version='TLSv1.1'
> ssl_min_protocol_version='TLSv1.2'
> ssl_max_protocol_version=''
>
> I copied the named files from src/test/ssl/ssl/ into pgdata, and I ran
> chmod 600 on the .key file.
>
> I put this into pgdata/pg_hba.conf at the top:
>
> hostssl all all 127.0.0.1/32 cert clientcert=verify-full
>
> I made a copy of src/test/ssl/ssl/client-revoked.key and ran chmod 600 on
> it.
>

Would it be feasible to capture this in a sort of a regression (TAP?) test?

--
Alex