| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | peter(at)eisentraut(dot)org |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: BackendKeyData is mandatory? |
| Date: | 2025-06-19 10:03:01 |
| Message-ID: | 20250619.190301.2272783561862817383.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I think that's fine, if the server does not want to support query
> cancellation. The current protocol description certainly does not
> support the idea that it is a hard error *not* to send BackendKeyData.
Isn't it scary if the server does not allow a query cancel? For
example, if the server charge you per query duration and if you
accidentally send a long running query, the only escape exit is the
query cancellation.
> It's also worth thinking about the new protocol 3.2 longer key data.
> A paranoid server might choose to send key data only if protocol >=3.2
> is chosen and not if a lower, notionally less secure version is
> chosen.
I would say the server does wrong a decision. I think even if the key
is not long, it's still useful than nothing.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2025-06-19 10:20:31 | Re: BackendKeyData is mandatory? |
| Previous Message | Amit Kapila | 2025-06-19 09:32:20 | Re: Conflict detection for update_deleted in logical replication |