On Thu, Jun 4, 2020 at 5:37 AM Thomas Munro <thomas.mu...@gmail.com> wrote:
> On Thu, Jun 4, 2020 at 1:53 PM Thomas Munro <thomas.mu...@gmail.com> > wrote: > > On Thu, Jun 4, 2020 at 1:35 PM Tom Lane <t...@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
