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.96) (envelope-from ) id 1vmXyO-00DISS-1B for pgsql-hackers@arkaria.postgresql.org; Sun, 01 Feb 2026 13:58:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vmXyK-009tQu-26 for pgsql-hackers@arkaria.postgresql.org; Sun, 01 Feb 2026 13:58:41 +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.96) (envelope-from ) id 1vmXyK-009tQm-0y for pgsql-hackers@lists.postgresql.org; Sun, 01 Feb 2026 13:58:41 +0000 Received: from udcm-wwu2.uni-muenster.de ([128.176.118.28]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vmXyI-000000002gT-02aD for pgsql-hackers@lists.postgresql.org; Sun, 01 Feb 2026 13:58:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-muenster.de; i=@uni-muenster.de; q=dns/txt; s=uniout; t=1769954318; x=1801490318; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=p7xa5bGE6rTNuH3LOuWChz29qyuDjxlkdOyMjnunWjU=; b=hHY/h/T1lkMuIVODtmC3CZfkouYNJC1hawhl+468zmRp9CzwSVqhJovi aqk2ukZtVb65LFpAmUTBI+GP5U3Lu50bn13wmQiTc8rBgYWXhNGiqgjY3 dFElyBpN5ON1j3I2BqYzOZSzrgr0o9PVgEnrx6giaXYCa8D7B713/jDWR e05ry7YOIxq4Ia/Yy7elJbOlKQsnCREefKtN0Z+x53Kk7Qx5p9lcabgTU /Rd/cEdNsUrZjpQ8rCc6p5MiMGaX3FqV/bsfzTOZNBQjvt3UZq2BqM2OP 7e7WsVANbT0aQfYhMuqJ3QSHuyFDT3RjmcAuXifJ3u/F/EweWr+wOthBZ w==; X-CSE-ConnectionGUID: vW9BOOmnQ6alm9W91OAMag== X-CSE-MsgGUID: ublIPgs5RDm3rzCKwjwqvw== X-IronPort-AV: E=Sophos;i="6.21,266,1763420400"; d="scan'208";a="383225722" Received: from secmail.uni-muenster.de ([128.176.118.4]) by UDCM-RELAY2.UNI-MUENSTER.DE with ESMTP; 01 Feb 2026 14:58:35 +0100 Received: from [192.168.178.27] (unknown [78.48.236.194]) by SECMAIL.UNI-MUENSTER.DE (Postfix) with ESMTPSA id AA75D20ADF00; Sun, 1 Feb 2026 14:58:33 +0100 (CET) Message-ID: <7e8c913b-1bfb-41f1-b5db-c29e2af48daa@uni-muenster.de> Date: Sun, 1 Feb 2026 14:58:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Additional message in pg_terminate_backend From: Jim Jones To: Kirill Reshke , Roman Khapov Cc: Daniel Gustafsson , pgsql-hackers@lists.postgresql.org References: <064E214D-D86F-4917-A0B6-67EAD6BCB24A@yandex-team.ru> <99f3524c-6aee-4fe2-8f3f-fcf0b67642c2@uni-muenster.de> Content-Language: de-DE, en-GB In-Reply-To: <99f3524c-6aee-4fe2-8f3f-fcf0b67642c2@uni-muenster.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 01/02/2026 01:08, Jim Jones wrote: > As pointed out by Kirill, there is no reason to create > pg_terminate_backend_msg or pg_cancel_backend_msg. You can simply use > the existing functions and expand them to use one extra parameter Since the message's size is limited to BACKEND_MSG_MAX_LEN, shouldn't you use it to limit msg at pg_terminate_backend[_msg]()? Something like: Datum pg_terminate_backend(PG_FUNCTION_ARGS) { int pid; int timeout; /* milliseconds */ char msg[BACKEND_MSG_MAX_LEN]; pid = PG_GETARG_INT32(0); timeout = PG_GETARG_INT64(1); text_to_cstring_buffer(PG_GETARG_TEXT_PP(2), msg, sizeof(msg)); return pg_terminate_backend_internal(pid, timeout, msg); }