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 1tkmY8-006l8H-2z for pgsql-admin@arkaria.postgresql.org; Wed, 19 Feb 2025 16:03:48 +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 1tkmY6-00ARMV-DO for pgsql-admin@arkaria.postgresql.org; Wed, 19 Feb 2025 16:03:46 +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 1tkmY6-00ARMN-1W for pgsql-admin@lists.postgresql.org; Wed, 19 Feb 2025 16:03:46 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tkmY4-001joa-1c for pgsql-admin@lists.postgresql.org; Wed, 19 Feb 2025 16:03:45 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 51JG3fPK2018444; Wed, 19 Feb 2025 11:03:41 -0500 From: Tom Lane To: Ron Johnson cc: Pgsql-admin Subject: Re: Does export operation cancel SQLs? In-reply-to: References: <098b7dbed4aa52c97b6159b26c36129ff2f10409.camel@cybertec.at> Comments: In-reply-to Ron Johnson message dated "Wed, 19 Feb 2025 10:42:54 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2018442.1739981021.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 19 Feb 2025 11:03:41 -0500 Message-ID: <2018443.1739981021@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Ron Johnson writes: > On Wed, Feb 19, 2025 at 10:00 AM Laurenz Albe > wrote: >> No, that message is from a cancel request, like when you interrupt your >> currently running query with Ctrl+C in "psql" or invoke >> pg_cancel_backend(). >> PostgreSQL doesn't do that by itself. > The Linux oom killer? I don't remember the exact error message that PG > gives to the user, but ISTR that it's "user request”. No, the OOM killer does "kill -9", which stops the PG process in its tracks. So no message at all will be issued. You'll get some kind of "connection lost" message from the connected client, but for sure that is not going to claim it was a "user request". I do seem to recall that there are some edge cases where we can't really tell the source of a SIGINT signal, but there's no reason to think that any of those cases are in play here. The OP should be looking first at the other moving parts in his installation to see what might be issuing a query cancel. regards, tom lane