> 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
