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 1w7FPE-0056zi-1u for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 16:24:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7FPD-004frY-06 for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Mar 2026 16:23:59 +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.96) (envelope-from ) id 1w7FPC-004frO-26 for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 16:23:59 +0000 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w7FPA-000000021T7-1qZ3 for pgsql-hackers@lists.postgresql.org; Mon, 30 Mar 2026 16:23:58 +0000 Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5a12c19affeso7930383e87.1 for ; Mon, 30 Mar 2026 09:23:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774887836; cv=none; d=google.com; s=arc-20240605; b=M4kPTeplz9Msx0zn4yFFW28Zioy6+WatXhHVutMG1T6xdFVKasc2z8/eyt+DJCDmqD /IGTT5+Geqk3NXbd1WjSTRj0giiyX7IF9LHo+TAmlyf06YNaVnuairh/DemeAe8gSpbO 5rpSFG141GWsNTsCy+fx/8TRmCt4C3eJIQoCEMJ3is7QRCaxVuCtPR5V5AgSjgpPV0d8 Vjkzpl+SUsMSHL1U65HWr08PCwSk2m+Njn5VfJBdjiRFmaDCS+YlCb/fAlnhg3YOPBai sq9czGzncqN6DAmDE9q/8rB1evgpXdOPYCXlfvKSNowDc+ouHI2urAN66+MEBhiTLRoA AzVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=NELxF/vJ9b9ssdiZM843eKMoWJSejSlanYUWtBaXO4k=; fh=sAAksBsXbuBMrVmbYq+hok5xI/JgQyIpgRc4yonb0sE=; b=BbfgFINk5+q0DA86AkgtOcq7VAS7kX2iVcIlvGrswurO3gEbXv9NHwMJNBp+M23l0V ygVBsyWVNooyp0y6T/FAtLIQZxy/usFcvzbYJsgF4u54BA9/onxtYzsgXSn7PwpN14gN eXpsexbIlhSv9MMaBoPBKvL0Fmjnv5UFOtC9rFDRtQcVJz7qfUPNsFwlPrzm4VyET9ig mnJFB65frDZhDWlr/p2KQ07drlXZAQ/ZluAgUr71VHa/M8/alFm/2fRFEjTkbspHIZuK 0zdNCCdqvPxQ36DFSR5cxHEkXvICHNWaw8K8Kz+vdusMWy0UE657C/1oQIUHG2qv18tz CVgQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeltef.nl; s=google; t=1774887836; x=1775492636; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NELxF/vJ9b9ssdiZM843eKMoWJSejSlanYUWtBaXO4k=; b=WqnUSUqCmaAEh9y2A4/M0AkeFj2yn7w6sTyS9GnXlbLnsZYMeLwE/802Q4MdRlpmcI RAp6C0PfL3xMcmPSrrMiZ200H+pvHT/XIHkX52M8bImCEQa4xoyJ4Z6kgyjs1aXBp9UF PjXXkEemPumorrabSI03OiBgM0ZJ+FLFbIUDMTHT4k2mWULBSFUMThgOjF2bQZtvUXsW WPaJD2kfuQ3zzalCjA/qaSH/s/2i6QHaNyYDxRID67oxKVIvRlihp6obcc8ZliWbYYEb YEwC+FZ7PB8ODmPtjfuwDPafzl5XuCGJNfnOsJWCAWT4E8jrc6ZWsTBPKyVpYDxi20F8 bhQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774887836; x=1775492636; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NELxF/vJ9b9ssdiZM843eKMoWJSejSlanYUWtBaXO4k=; b=BdxotYoEhSrONCTcEu5zGt9HJxjUJfBPGuFALY4uqptGKwNiKIETlt2fDpN9OI/oHS nOYWgEfURd1RAI94oyBTQsvabb7SME6XX+z20dBbD2QH+IkiWVVJzN4C6Jtre6sdtT/G Rcos2fnniVZWvvwtDo/uZb7nElEUqxaPr8JVA7sbHmAPAVqV5PhyuqwM+uQfuwJLO0lu 96OoCfqdXkrGdS4vVv38B2DUaxqgttMwjlAIkNNsNquIj0zypfev8SwUup9KKVDD3IaV hpUS469up/zFpKJWtApBjpKOrrW8TliDeFigwu/nWQtH836OTB+1BM6KAgFLl9BMi3B8 7vDw== X-Forwarded-Encrypted: i=1; AJvYcCUyY4EoKQ67Xz3ieGZ9m9VttLtu0RqjTaydfK7tzkXtXy2N0NFEks/Mn2LKRmRAlcP5h9Sg6r4CHeT/kPdB@lists.postgresql.org X-Gm-Message-State: AOJu0YwF8mYdq89A+veAg2ebt6lOqMuVz2XiaVpWs87boUrYBvpHleyi ZtgB+z29iD2IpmXCLUuLNgbQuHVTsvU4mIRLEskYiUkX2R+6Y4h4++eAqoIDRqYlvCBTLjI377r t0HR4NT/PWVy0KVgoIJqejO87JdMTyCjapI8BnmCjmA== X-Gm-Gg: ATEYQzxGwOOZB3pPPE0BRTAxjJKECSnKbIRwFDq2hoHWVQvOJI8B61ckGZafr+dW+v/ 9Ve4lA+1dWTDydBSwAyZrOTvR0pjKR8+VnlYQjyEN+FAabrxgk1NHPCxUCWftn7FdYYPCHmY1KW 3rH3RzjEfNW1wFihrZd2gcSbFPvzNpbLFxs1e3gi1Jz1bQfEcIocuROrslKfdC6m4MNpKqW/uUU Khl8/Cazfw4rJgl5Gh0XPamaniftflnkB6OmD5nN5CeFGe+v4Dp8yoxi9cu7UPjVmqAQ5+BYOqr 81pnu99CkKQF2OQo X-Received: by 2002:a05:6512:2385:b0:5a2:7cde:3438 with SMTP id 2adb3069b0e04-5a2bab15cd6mr72250e87.22.1774887835044; Mon, 30 Mar 2026 09:23:55 -0700 (PDT) MIME-Version: 1.0 References: <20260325.093620.1348358766802101218.ishii@postgresql.org> In-Reply-To: <20260325.093620.1348358766802101218.ishii@postgresql.org> From: Jelte Fennema-Nio Date: Mon, 30 Mar 2026 18:23:43 +0200 X-Gm-Features: AQROBzDPif80gzM3J5eN8haddhgiTzpylJt48bt6jsTuexBazgvaKkoENOZs-CE Message-ID: Subject: Re: Add GoAway protocol message for graceful but fast server shutdown/switchover To: Tatsuo Ishii Cc: jacob.champion@enterprisedb.com, tomas@vondra.me, zsolt.parragi@percona.com, pgsql-hackers@lists.postgresql.org, davecramer@gmail.com, hlinnaka@iki.fi Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 25 Mar 2026 at 01:36, Tatsuo Ishii wrote: > 1. If clients do not disconnect a session even if they have received > the GoAway message, PostgreSQL server will give up the shutdown > sequence. In this case, shouldn't the PostgreSQL server send a > message indicating "I have given up the smart shutdown request"? > Otherwise, the fact that GoAway has been received will remain in > the client, and if the client does not check the receiving timely, > the client may exit the session unnecessarily. You mean effectively being able to undo sending the GoAway message? As the patch is right now, the server will never give up on the shutdown sequence. It will wait indefinitely until it can shut down. This is unchanged from the current smart shutdown mode behaviour on master. I think it's an interesting idea, but I don't think it's worth the cost of implementing and maintaining. I don't think it's common for programs to support cancelling a shutdown sequence. I can't think of any databases or network services I worked with that support it. Generally if you want something to shut down, there's a slow graceful way, and a fast non-graceful way. I personally when the slow graceful shutdown did not finish "in time for me", I have never felt the need to cancel the shutdown sequence. Instead I normally trigger the fast non-graceful shutdown at that point (either manually or through some automated timeout). > 2. Can we use a NOTICE message instead of the new protocol GoAway for > the purpose? It's a good question. Sadly not easily, e.g. `client_min_messages` WARNING or ERROR will make sure that won't get sent to the client. I also thought about adding a read-only parameter and use ParameterStatus instead of a new message, i.e. similar to how a server reports its hot_standby status. A significant issue also arises when the connection isn't made directly to Postgres, but instead involving poolers like PgBouncer. The GoAway signal is conceptually a link-level message, i.e. it's about the connection directly to Postgres that should be disconnected. But generally proxies forward all messages from Postgres to the client. But if it does that, the client will disconnect, while the pooler keeps the connection open to the server. So now the client disconnected from PgBouncer for no reason, but the connection to Postgres is still there. I don't think that's behaviour we want to happen. That's why I think it would actually be good to have the GoAway message be opt-in at the connection level, so if an old PgBouncer doesn't know how to deal with it, it won't forward it accidentally to the client.