> Or disconnect.
You cannot disconnect without canceling the query at least using psql.
You can kill psql to disconnect but it's possible that the backend
keeps on running the query.
> Or pg_cancel_backend().
In order to issue pg_cancel_backend() the user needs to know the
backend pid which was supposed to be provided by a BackendKeyData
message. Of course you could search and find the backend pid from
other source, but I think it's less user friendly.
>> I would say the server does wrong a decision. I think even if the key
>> is not long, it's still useful than nothing.
>
> I tend to agree, but people have different priorities. It's also
> reasonable that you'd want to only support long cancellation keys. Or
> maybe you have a proxy that doesn't implement query cancellation, or
> only supports it with long keys because it embeds routing information
> in the key, or something like that.
Agreed. All PostgreSQL "compatible" servers have their own
priority. In Pgpool-II case, the priority is compatibility with
PostgreSQL (I am not saying Pgpool-II is 100% compatible with
PostgreSQL as of today, but it's a implementation limitation which I
want to eliminate someday).
> FWIW my reading of the protocol docs is that BackendKeyData is
> optional.
If majority of developers think so, do we want to update the protocol
docs? For me the docs is not clear enough.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
