| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Make query cancellation keys longer |
| Date: | 2024-09-05 16:21:29 |
| Message-ID: | 1995353.1725553289@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> writes:
> Has there been any work/discussion around not sending the cancel key
> in plaintext from psql? It's not a prerequisite or anything (the
> longer length is a clear improvement either way), but it seems odd
> that this longer "secret" is still just going to be exposed on the
> wire when you press Ctrl+C.
Wasn't this already addressed in v17, by
Author: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
2024-03-12 [61461a300] libpq: Add encrypted and non-blocking query cancellation
? Perhaps we need to run around and make sure none of our standard
clients use the old API anymore, but the libpq infrastructure is
there already.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-09-05 16:25:27 | Re: scalability bottlenecks with (many) partitions (and more) |
| Previous Message | Maxim Orlov | 2024-09-05 16:08:58 | Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points |