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 1t9Q9W-00A33U-As for pgsql-general@arkaria.postgresql.org; Fri, 08 Nov 2024 14:39:57 +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 1t9Q9S-009pPx-AI for pgsql-general@arkaria.postgresql.org; Fri, 08 Nov 2024 14:39:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Q9R-009pPo-Vq for pgsql-general@lists.postgresql.org; Fri, 08 Nov 2024 14:39:54 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Q9N-000rbY-VQ for pgsql-general@lists.postgresql.org; Fri, 08 Nov 2024 14:39:53 +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 4A8Edm7Z3628360; Fri, 8 Nov 2024 09:39:48 -0500 From: Tom Lane To: =?UTF-8?Q?Micha=C5=82_Albrycht?= cc: pgsql-general@lists.postgresql.org Subject: Re: Why plpython functions increase transaction counter much more then plpgsql functions? In-reply-to: References: Comments: In-reply-to =?UTF-8?Q?Micha=C5=82_Albrycht?= message dated "Fri, 08 Nov 2024 08:58:47 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3628358.1731076788.1@sss.pgh.pa.us> Date: Fri, 08 Nov 2024 09:39:48 -0500 Message-ID: <3628359.1731076788@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =?UTF-8?Q?Micha=C5=82_Albrycht?= writes: > This proves that the plpython function affects the transaction counter much > more. Does anyone know why? A quick look at PLy_spi_execute_query shows that it runs each command in a subtransaction. It pretty much has to, because the coding rules for a Python method don't permit it to just longjmp out of the Python interpreter, so it has to set up a subtransaction so it can catch any error. In this example, each subtransaction will consume an XID. The plpgsql example is different because it doesn't trap errors, hence no subtransaction needed, and all the rows will get inserted under the XID of the outer command's main transaction. If you were to wrap the insert_row_to_db call in BEGIN ... EXCEPTION then it'd consume the same number of XIDs as plpython, for the same reason. > Is there anything I can do about it? Batch the DB updates, perhaps? > What's interesting it happens only if the function called by plpyhon makes > changes to DB. Totally unsurprising. XIDs are acquired only when the current transaction or subtransaction first needs to change the DB. regards, tom lane