On 03/04/2025 14:29, Daniel Gustafsson wrote:
On 2 Apr 2025, at 15:48, Heikki Linnakangas wrote:
And committed, with minor a bunch more little cleanups.
0001 in commit 09be39112654 seems to have missed (omitted?) adding the HAVE_
macros to pg_config.h.in, which doesn't matter as of now sinc
> On 2 Apr 2025, at 15:48, Heikki Linnakangas wrote:
> And committed, with minor a bunch more little cleanups.
0001 in commit 09be39112654 seems to have missed (omitted?) adding the HAVE_
macros to pg_config.h.in, which doesn't matter as of now since they're not used
but it will be in the way fo
On 01/04/2025 17:08, Heikki Linnakangas wrote:
I think this is pretty much ready for commit. I will go over it one more
time, and plan to push tomorrow.
And committed, with minor a bunch more little cleanups.
Thank you to everyone involved, in particular Jelte, Robert and Jacob! I
read throug
On 22/02/2025 16:58, Jelte Fennema-Nio wrote:
On Mon, 9 Sept 2024 at 17:58, Robert Haas wrote:
On Fri, Aug 16, 2024 at 11:29 AM Robert Haas wrote:
I'll split this patch like that, to make it easier to compare and merge
with Jelte's corresponding patches.
That sounds great. IMHO, comparing
On Tue, Feb 25, 2025 at 9:28 AM Jelte Fennema-Nio wrote:
> So to be clear: the current patchset *does not* change any client
> defaults. libpq will still connect to a server using the protocol
> version 3.0 by default. It will only connect with 3.2 unless
> instructed explicitly in the connection
On Mon, 24 Feb 2025 at 18:24, Robert Haas wrote:
>
> On Sat, Feb 22, 2025 at 9:58 AM Jelte Fennema-Nio wrote:
> > My patchset in the other protocol thread needed a rebase. So I took
> > that as an opportunity to rebase this patchset on top of it, because
> > this seems to be the protocol change t
On Sat, Feb 22, 2025 at 9:58 AM Jelte Fennema-Nio wrote:
> My patchset in the other protocol thread needed a rebase. So I took
> that as an opportunity to rebase this patchset on top of it, because
> this seems to be the protocol change that we can most easily push over
> the finish line.
I'm sti
On Mon, 9 Sept 2024 at 17:58, Robert Haas wrote:
>
> On Fri, Aug 16, 2024 at 11:29 AM Robert Haas wrote:
> > > I'll split this patch like that, to make it easier to compare and merge
> > > with Jelte's corresponding patches.
> >
> > That sounds great. IMHO, comparing and merging the patches is th
On Fri, Aug 16, 2024 at 11:29 AM Robert Haas wrote:
> > I'll split this patch like that, to make it easier to compare and merge
> > with Jelte's corresponding patches.
>
> That sounds great. IMHO, comparing and merging the patches is the next
> step here and would be great to see.
Heikki, do you
On Thu, Sep 5, 2024 at 9:36 AM Jelte Fennema-Nio wrote:
> Totally agreed that it would be good to update psql to use the new
> much more secure libpq function introduced in PG17[1]. This is not a
> trivial change though because it requires refactoring the way we
> handle signals (which is why I di
On Thu, 5 Sept 2024 at 17:43, Jacob Champion
wrote:
> 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 ju
On Thu, Sep 5, 2024 at 9:21 AM Tom Lane wrote:
> Wasn't this already addressed in v17, by
>
> Author: Alvaro Herrera
> 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 A
Jacob Champion 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
On Thu, Aug 15, 2024 at 10:14 AM Heikki Linnakangas wrote:
> I'm back to working on the main patch here, to make cancellation keys
> longer. New rebased version attached, with all the FIXMEs and TODOs from
> the earlier version fixed. There was a lot of bitrot, too.
I have a couple of questions/c
On Fri, Aug 16, 2024 at 10:37 AM Heikki Linnakangas wrote:
> If we envision accepting ranges like that in the future, it would be
> good to do now rather than later. Otherwise, if someone wants to require
> features from protocol 3.2 today, they will have to put
> "protocol_version=3.2" in the con
On 16/08/2024 15:31, Robert Haas wrote:
On Thu, Aug 15, 2024 at 6:07 PM Heikki Linnakangas wrote:
Ok, I've read through that thread now, and opined there too. One
difference is with libpq option name: My patch adds "protocol_version",
while Jelte proposes "max_protocol_version". I don't have st
On Thu, Aug 15, 2024 at 6:07 PM Heikki Linnakangas wrote:
> Ok, I've read through that thread now, and opined there too. One
> difference is with libpq option name: My patch adds "protocol_version",
> while Jelte proposes "max_protocol_version". I don't have strong
> opinions on that. I hope the e
On 15/08/2024 23:20, Robert Haas wrote:
On Thu, Aug 15, 2024 at 1:13 PM Heikki Linnakangas wrote:
Added a "protocol_version" libpq option for that. It defaults to "auto",
but you can set it to "3.1" or "3.0" to force the version. It makes it
easier to test that the backwards-compatibility works
On Thu, Aug 15, 2024 at 1:13 PM Heikki Linnakangas wrote:
> Added a "protocol_version" libpq option for that. It defaults to "auto",
> but you can set it to "3.1" or "3.0" to force the version. It makes it
> easier to test that the backwards-compatibility works, too.
Over on the "Add new protocol
I'm back to working on the main patch here, to make cancellation keys
longer. New rebased version attached, with all the FIXMEs and TODOs from
the earlier version fixed. There was a lot of bitrot, too.
The first patch now introduces timingsafe_bcmp(), a function borrowed
from OpenBSD to perfor
+ * See if we have a matching backend. Reading the pss_pid and
+ * pss_cancel_key fields is racy, a backend might die and remove itself
+ * from the array at any time. The probability of the cancellation key
+ * matching wrong process is miniscule, however, so we can live with that
On 24/07/2024 19:12, Heikki Linnakangas wrote:
On 04/07/2024 15:20, Jelte Fennema-Nio wrote:
On Thu, 4 Jul 2024 at 12:32, Heikki Linnakangas wrote:
We currently don't do any locking on the ProcSignal array. For query
cancellations, that's good because a query cancel packet is processed
without
On 04/07/2024 15:20, Jelte Fennema-Nio wrote:
On Thu, 4 Jul 2024 at 12:32, Heikki Linnakangas wrote:
We currently don't do any locking on the ProcSignal array. For query
cancellations, that's good because a query cancel packet is processed
without having a PGPROC entry, so we cannot take LWLock
On Thu, 4 Jul 2024 at 14:43, Tomas Vondra wrote:
> I don't have any immediate feedback regarding this patch, but I'm
> wondering about one thing related to cancellations - we talk cancelling
> a query, but we really target a PID (or a particular backend, no matter
> how we identify it).
>
> I occa
Hi,
I don't have any immediate feedback regarding this patch, but I'm
wondering about one thing related to cancellations - we talk cancelling
a query, but we really target a PID (or a particular backend, no matter
how we identify it).
I occasionally want to only cancel a particular query, but I d
On Thu, 4 Jul 2024 at 12:32, Heikki Linnakangas wrote:
> We currently don't do any locking on the ProcSignal array. For query
> cancellations, that's good because a query cancel packet is processed
> without having a PGPROC entry, so we cannot take LWLocks. We could use
> spinlocks though. In this
On 04/07/2024 13:50, Jelte Fennema-Nio wrote:
On Thu, 4 Jul 2024 at 12:35, Heikki Linnakangas wrote:
On 04/07/2024 13:32, Heikki Linnakangas wrote:
Here's a new version of the first patch.
Sorry, forgot attachment.
It seems you undid the following earlier change. Was that on purpose?
If n
On Thu, 4 Jul 2024 at 12:35, Heikki Linnakangas wrote:
>
> On 04/07/2024 13:32, Heikki Linnakangas wrote:
> > Here's a new version of the first patch.
>
> Sorry, forgot attachment.
It seems you undid the following earlier change. Was that on purpose?
If not, did you undo any other earlier changes
On 04/07/2024 13:32, Heikki Linnakangas wrote:
Here's a new version of the first patch.
Sorry, forgot attachment.
--
Heikki Linnakangas
Neon (https://neon.tech)
From e9fc1f4365077673c71ba138a0ae7fbcebe16a36 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas
Date: Thu, 4 Jul 2024 01:03:15 +0300
Here's a new version of the first patch. In the previous version, I
added the pid cancellation key to pmsignal.c, but on second thoughts, I
think procsignal.c is a better place. The ProcSignal array already
contains the pid, we just need to add the cancellation key there.
This first patch just
On Fri, Mar 8, 2024 at 5:20 PM Heikki Linnakangas wrote:
> The nice thing about relying on the message length was that we could
> just redefine the CancelRequest message to have a variable length
> secret, and old CancelRequest with 4-byte secret was compatible with the
> new definition too. But i
On Fri, 8 Mar 2024 at 23:20, Heikki Linnakangas wrote:
> Added some documentation. There's more work to be done there, but at
> least the message type descriptions are now up-to-date.
Thanks, that's very helpful.
> The nice thing about relying on the message length was that we could
> just redef
On 01/03/2024 07:19, Jelte Fennema-Nio wrote:
I think this behaviour makes more sense as a minor protocol version
bump instead of a parameter.
Ok, the consensus is to bump the minor protocol version for this. Works
for me.
+ if (strcmp(conn->workBuffer.data, "_pq_.extended_query_cancel") == 0
On Fri, Mar 1, 2024 at 03:19:23PM +0100, Peter Eisentraut wrote:
> On 29.02.24 22:25, Heikki Linnakangas wrote:
> > Currently, cancel request key is a 32-bit token, which isn't very much
> > entropy. If you want to cancel another session's query, you can
> > brute-force it. In most environments, a
On Sun, 3 Mar 2024 at 15:27, Jelte Fennema-Nio wrote:
> + case EOF:
> + /* We'll come back when there is more data */
> + return PGRES_POLLING_READING;
>
> Nice catch, I'll go steal this for my patchset which adds all the
> necessary changes to be able to do a protocol bump[1].
Actually, it turns
On Fri, 1 Mar 2024 at 06:19, Jelte Fennema-Nio wrote:
> This is a preliminary review. I'll look at this more closely soon.
Some more thoughts after looking some more at the proposed changes
+#define EXTENDED_CANCEL_REQUEST_CODE PG_PROTOCOL(1234,5677)
nit: I think the code should be 1234,5679 be
On Fri, 1 Mar 2024 at 15:19, Peter Eisentraut wrote:
> > One complication with this was that because we no longer know how long
> > the key should be, 4-bytes or something longer, until the backend has
> > performed the protocol negotiation, we cannot generate the key in the
> > postmaster before
On 29.02.24 22:25, Heikki Linnakangas wrote:
Currently, cancel request key is a 32-bit token, which isn't very much
entropy. If you want to cancel another session's query, you can
brute-force it. In most environments, an unauthorized cancellation of a
query isn't very serious, but it neverthele
This is a preliminary review. I'll look at this more closely soon.
On Thu, 29 Feb 2024 at 22:26, Heikki Linnakangas wrote:
> If the client requests the "_pq_.extended_query_cancel" protocol
> feature, the server will generate a longer 256-bit cancellation key.
Huge +1 for this general idea. This
Currently, cancel request key is a 32-bit token, which isn't very much
entropy. If you want to cancel another session's query, you can
brute-force it. In most environments, an unauthorized cancellation of a
query isn't very serious, but it nevertheless would be nice to have more
protection from
40 matches
Mail list logo
