Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sibA4-006nPC-HA for pgsql-admin@arkaria.postgresql.org; Mon, 26 Aug 2024 14:57:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sibA1-00B7qg-Md for pgsql-admin@arkaria.postgresql.org; Mon, 26 Aug 2024 14:57:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sibA1-00B7qX-4K for pgsql-admin@lists.postgresql.org; Mon, 26 Aug 2024 14:57:37 +0000 Received: from forward102d.mail.yandex.net ([178.154.239.213]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sib9x-001XH0-0Q for pgsql-admin@lists.postgresql.org; Mon, 26 Aug 2024 14:57:36 +0000 Received: from mail-nwsmtp-smtp-production-main-13.klg.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-13.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:49a7:0:640:c0e6:0]) by forward102d.mail.yandex.net (Yandex) with ESMTPS id B612D60981 for ; Mon, 26 Aug 2024 17:57:27 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-13.klg.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id QvUSFv0oDCg0-fEwEECIe; Mon, 26 Aug 2024 17:57:27 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1724684247; bh=OJzikI5TJNz32Kjt4pVu8IIim2mGZNf9dqQFJGCpGFM=; h=To:Subject:From:Date:Message-ID; b=dK7p9NKUSdr0Qx71xaCY2HajJ7lxCEPl1BBkZxVyDBHJCPis+oMWPBJ3Y0avf78Kr PrbC/wekPP3fL8zFRbVCSoyRHBj/+gD3rvI/fHxXe7Yd+7YklDw59C4xJJk1dOW1ql cG1vHbuBudn5+GNQUfwxUdBp3/QDvnGzxSpHgbfQ= Authentication-Results: mail-nwsmtp-smtp-production-main-13.klg.yp-c.yandex.net; dkim=pass header.i=@ya.ru Message-ID: <7af72094-8bd6-4fe0-8578-0badcb237c6d@ya.ru> Date: Mon, 26 Aug 2024 17:57:26 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: splarv@ya.ru Subject: complain about closing bugreports with wrong reason To: pgsql-admin@lists.postgresql.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi all. There is a bug in PgAdmin, if I use an option "set role" in the connection dialog, I will not be able to cancel query anymore. How to recreate. Config connection to a server to use "set role": the dialog "properties" of a server, tab "connection", field "Role" assign to DBO, without superuser privilege. Run query, for instance "select pg_sleep(10000)" and try to finish it. You will get ERROR: permission denied to cancel query DETAIL: Only roles with privileges of the role whose query is being canceled or with privileges of the "pg_signal_backend" role may cancel this query. STATEMENT: SELECT pg_cancel_backend(497843); First bug in the issue tracker is: https://github.com/pgadmin-org/pgadmin4/issues/7442 The answer to assign user to the role pg_signal_backend is wrong and will rise even security issue, the user will be able to terminate not only his query, but everyone. I reopened this bugreport for this reason. https://github.com/pgadmin-org/pgadmin4/issues/7821 The answer was just lie: The connection made using the details from server dialog is used everywhere. pgAdmin cannot create a connection separately without the role specified and execute pg_cancel_backend. This is not a bug. This behaviour is same as psql. End cite. The lie because a psql and DBeaver worked perfectly in this situation. Everyone can set role in DBeaver connection dialog or in the psql "set role dbo" after connection, run query and cancel query. This doesn't work only in the PgAdmin and only due to reason, because developers simply close bugs instead on fixing it. If your way do nothing with buggy behavior of "set role", then just remove it from the connection dialog. -- Olleg