Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mx8Yj-00069S-26 for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Dec 2021 14:13:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mx8Yh-0000rv-Hb for pgsql-hackers@arkaria.postgresql.org; Tue, 14 Dec 2021 14:13:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mx8Yh-0000rl-6m for pgsql-hackers@lists.postgresql.org; Tue, 14 Dec 2021 14:13:35 +0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mx8Yd-0002kn-Vk for pgsql-hackers@postgresql.org; Tue, 14 Dec 2021 14:13:34 +0000 Received: by mail-pf1-x430.google.com with SMTP id g18so17932798pfk.5 for ; Tue, 14 Dec 2021 06:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=00diKwDLdDi+hxYd/WFkHlGieIkPd/I3x/qSfVQX7ss=; b=m15wPO92BcOKSD1BxTQnTHOdVUjxCSnsOpnLueXPUaDGtbHWWCy1B5V2o3JqCcaXwS DBNTQ3HbxnzMOW2VcYNEykU2iM+zuieUDRV4Vxwffcix+W2+y4jR+Gw2skKwLQpBxBzs Vnco5lCBNUghwjlQAT9lY5hFPWkgb0vzVKPnBQueYSet6DEl4geYfMgiO/Ktk31gXo3y dTS12uH9jjo7RmPsy9JriBzmByICcCW1wlTulSGJOR7l1MpxdEqpkyaegSrI2lstSY0k HvxVFCRmLgIb54B9HjRq63GbUhXzPDNgsXKnbY1TVzT5THoHzd3SupuB2hgre8LvWocd +HLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=00diKwDLdDi+hxYd/WFkHlGieIkPd/I3x/qSfVQX7ss=; b=bdCVn7C2KEH08jsxUP/52EXseBUS36azBA1rGSVu5dN2ZhA6hYHcZP2huPN9QDNR4P 8goW0Itnz0YVTGEyBoBHT+F+7F09DsWDO9sfyF98z0rCToNBRt7R1hqedn55unf+zNgp TOKTh38IrQOmkid6eRFvP3z4vOyjAPHImGueFWTiiCb9ny1XOpN1bo6ifhd372FIE73R nyNURFIKAfjSD149gjpk2xbXdl/KMLmXHr3BMqqJPnSnWoqyPizXeuz3oBzgcKdRU4YO c5ZvvfF36qQ1dd/EJbZJdcT21CEZvSAarQvbDrKMhcGE5rL/CqMPlHOnJgfpmSBnTLS2 22CQ== X-Gm-Message-State: AOAM532td2mF74xLNmwhqmne4IM41CPs8gqDms0FsNZbfezCqR/oTE7r Sh6KUTJfGx07Ggxv6YSlBHbxFTpCCXr2NCDBA59IkwlKc4g= X-Google-Smtp-Source: ABdhPJxPVDyxW6UqFMxyUbvmOL85MlvK3jZNtznGTc6ssP9D3InHR9U2WpeNzRAPADpemuPR+GoElrD+om1eSh/TtWQ= X-Received: by 2002:a63:a18:: with SMTP id 24mr3959510pgk.100.1639491209054; Tue, 14 Dec 2021 06:13:29 -0800 (PST) MIME-Version: 1.0 References: <20211214.130456.2233153190058148084.horikyota.ntt@gmail.com> In-Reply-To: <20211214.130456.2233153190058148084.horikyota.ntt@gmail.com> From: Bharath Rupireddy Date: Tue, 14 Dec 2021 19:43:18 +0530 Message-ID: Subject: Re: more descriptive message for process termination due to max_slot_wal_keep_size To: Kyotaro Horiguchi Cc: PostgreSQL-development Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Dec 14, 2021 at 9:35 AM Kyotaro Horiguchi wrote: > > Hello. > > As complained in pgsql-bugs [1], when a process is terminated due to > max_slot_wal_keep_size, the related messages don't mention the root > cause for *the termination*. Note that the third message does not > show for temporary replication slots. > > [pid=a] LOG: "terminating process %d to release replication slot \"%s\"" > [pid=x] LOG: FATAL: terminating connection due to administrator command > [pid=a] LOG: invalidting slot "s" because its restart_lsn X/X exceeds max_slot_wal_keep_size > > The attached patch attaches a DETAIL line to the first message. > > > [17605] LOG: terminating process 17614 to release replication slot "s1" > + [17605] DETAIL: The slot's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size. > > [17614] FATAL: terminating connection due to administrator command > > [17605] LOG: invalidating slot "s1" because its restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size > > Somewhat the second and fourth lines look inconsistent each other but > that wouldn't be such a problem. I don't think we want to concatenate > the two lines together as the result is a bit too long. > > > LOG: terminating process 17614 to release replication slot "s1" because it's restart_lsn 0/2C0000A0 exceeds max_slot_wal_keep_size. > > What do you think about this? > > [1] https://www.postgresql.org/message-id/20211214.101137.379073733372253470.horikyota.ntt%40gmail.com +1 to give more context to the "terminating process %d to release replication slot \"%s\"" message. How about having below, instead of adding errdetail: "terminating process %d to release replication slot \"%s\" whose restart_lsn %X/%X exceeds max_slot_wal_keep_size"? I think we can keep the "invalidating slot \"%s\" because its restart_lsn %X/%X exceeds max_slot_wal_keep_size" message as-is. We may not see "terminating process ..." and "invalidation slot ..." messages together for the same slot, so having slightly different wording is fine IMO. Regards, Bharath Rupireddy.