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 1oVUQ1-00024U-F5 for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Sep 2022 08:58:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oVUPz-0005Sx-4R for pgsql-hackers@arkaria.postgresql.org; Tue, 06 Sep 2022 08:58:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVUPx-0005Sm-Rc for pgsql-hackers@lists.postgresql.org; Tue, 06 Sep 2022 08:58:50 +0000 Received: from smtp-fw-80006.amazon.com ([99.78.197.217]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVUPt-0005hi-Uy for pgsql-hackers@postgresql.org; Tue, 06 Sep 2022 08:58:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1662454726; x=1693990726; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to; bh=Y6ZrBo3pT91Yahu3YprK00rneamRjTO1uQ5PoVA2/Bw=; b=Pj5G972BOqex78p0k2DSBPg03vwoKelnpb9cIoPEuyf+s6LHQ5OmMqEX IPQ+OoDQeveJfpsEq9BC4WPEwMyG4E15rCg0h3QfkgMHl5DwrYfIb2Hoc WRjJ9/rndBQQganMNUk+MsIcGeM21AgJu3F2r6dWcBnyfKXgVq2sTGbMp M=; X-IronPort-AV: E=Sophos;i="5.93,293,1654560000"; d="scan'208,217";a="127055423" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-iad-1d-f20e0c8b.us-east-1.amazon.com) ([10.25.36.210]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Sep 2022 08:54:39 +0000 Received: from EX13D03EUC003.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1d-f20e0c8b.us-east-1.amazon.com (Postfix) with ESMTPS id 3E9278B014; Tue, 6 Sep 2022 08:54:38 +0000 (UTC) Received: from [192.168.7.133] (10.43.165.214) by EX13D03EUC003.ant.amazon.com (10.43.164.192) with Microsoft SMTP Server (TLS) id 15.0.1497.38; Tue, 6 Sep 2022 08:54:36 +0000 Content-Type: multipart/alternative; boundary="------------5T6Pk0Rd4GGc1Ep4eHEdi8gC" Message-ID: <03ee95c3-6496-90b7-5c8b-13fe69ee73dd@amazon.com> Date: Tue, 6 Sep 2022 10:54:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: more descriptive message for process termination due to max_slot_wal_keep_size To: Kyotaro Horiguchi CC: , , References: <20220104.102931.1400105396066285349.horikyota.ntt@gmail.com> <20220302.153719.171492355527427161.horikyota.ntt@gmail.com> <20220906.145336.1494945638376688936.horikyota.ntt@gmail.com> Content-Language: en-US From: "Drouvot, Bertrand" In-Reply-To: <20220906.145336.1494945638376688936.horikyota.ntt@gmail.com> X-Originating-IP: [10.43.165.214] X-ClientProxiedBy: EX13D51EUC001.ant.amazon.com (10.43.164.111) To EX13D03EUC003.ant.amazon.com (10.43.164.192) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --------------5T6Pk0Rd4GGc1Ep4eHEdi8gC Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, On 9/6/22 7:53 AM, Kyotaro Horiguchi wrote: > At Mon, 5 Sep 2022 11:56:33 +0200, "Drouvot, Bertrand" wrote in >> Hi, >> >> On 3/2/22 7:37 AM, Kyotaro Horiguchi wrote: >>> At Tue, 04 Jan 2022 10:29:31 +0900 (JST), Kyotaro >>> Horiguchi wrote in >>>> So what do you say if I propose the following? >>>> >>>> LOG: terminating process %d to release replication slot \"%s\" >>>> because its restart_lsn %X/%X exceeds the limit %X/%X >>>> HINT: You might need to increase max_slot_wal_keep_size. >>> This version emits the following message. >>> >>> [35785:checkpointer] LOG: terminating process 36368 to release >>> replication slot "s1" because its restart_lsn 0/1F000148 exceeds the >>> limit 0/21000000 >>> [35785:checkpointer] HINT: You might need to increase >>> max_slot_wal_keep_size. >> As the hint is to increase max_slot_wal_keep_size, what about >> reporting the difference in size (rather than the limit lsn)? >> Something along those lines? >> >> [35785:checkpointer] LOG: terminating process 36368 to release >> replication slot "s1" because its restart_lsn 0/1F000148 exceeds the >> limit by . > Thanks! That might be more sensible exactly for the reason you > mentioned. One issue doing that is size_pretty is dbsize.c local > function. Since the size is less than kB in many cases, we cannot use > fixed unit for that. Thanks for the new patch version!. I did not realized (sorry about that) that we'd need to expose byte_size_pretty(). Now I wonder if we should not simply report the number of bytes (like I can see it is done in many places). So something like: @@ -1298,9 +1298,9 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,                                 byte_size_pretty(buf, sizeof(buf), oldestLSN - restart_lsn);                                 ereport(LOG, - (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds the limit by %s", + (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds the limit by %lu bytes", active_pid, NameStr(slotname), - LSN_FORMAT_ARGS(restart_lsn), buf), + LSN_FORMAT_ARGS(restart_lsn), oldestLSN - restart_lsn),                                                  errhint("You might need to increase max_slot_wal_keep_size."))); and then forget about exposing/using byte_size_pretty() (that would be more consistent with the same kind of reporting in the existing code). What do you think? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services:https://aws.amazon.com --------------5T6Pk0Rd4GGc1Ep4eHEdi8gC Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Hi,

On 9/6/22 7:53 AM, Kyotaro Horiguchi wrote:
At Mon, 5 Sep 2022 11:56:33 +0200, "Drouvot, Bertrand" <bdrouvot@amazon.com> wrote in
Hi,

On 3/2/22 7:37 AM, Kyotaro Horiguchi wrote:
At Tue, 04 Jan 2022 10:29:31 +0900 (JST), Kyotaro
Horiguchi<horikyota.ntt@gmail.com> wrote in
So what do you say if I propose the following?

LOG:  terminating process %d to release replication slot \"%s\"
because its restart_lsn %X/%X exceeds the limit %X/%X
HINT: You might need to increase max_slot_wal_keep_size.
This version emits the following message.

[35785:checkpointer] LOG: terminating process 36368 to release
replication slot "s1" because its restart_lsn 0/1F000148 exceeds the
limit 0/21000000
[35785:checkpointer] HINT: You might need to increase
max_slot_wal_keep_size.
As the hint is to increase max_slot_wal_keep_size, what about
reporting the difference in size (rather than the limit lsn)?
Something along those lines?

[35785:checkpointer] LOG: terminating process 36368 to release
replication slot "s1" because its restart_lsn 0/1F000148 exceeds the
limit by <NNN MB>.
Thanks! That might be more sensible exactly for the reason you
mentioned.  One issue doing that is size_pretty is dbsize.c local
function. Since the size is less than kB in many cases, we cannot use
fixed unit for that.

Thanks for the new patch version!. I did not realized (sorry about that) that we'd need to expose byte_size_pretty(). Now I wonder if we should not simply report the number of bytes (like I can see it is done in many places). So something like:

@@ -1298,9 +1298,9 @@ InvalidatePossiblyObsoleteSlot(ReplicationSlot *s, XLogRecPtr oldestLSN,
                                byte_size_pretty(buf, sizeof(buf),
                                                                 oldestLSN - restart_lsn);
                                ereport(LOG,
-                                               (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds the limit by %s",
+                                               (errmsg("terminating process %d to release replication slot \"%s\" because its restart_lsn %X/%X exceeds the limit by %lu bytes",
                                                                active_pid, NameStr(slotname),
-                                                               LSN_FORMAT_ARGS(restart_lsn), buf),
+                                                               LSN_FORMAT_ARGS(restart_lsn), oldestLSN - restart_lsn),
                                                 errhint("You might need to increase max_slot_wal_keep_size.")));

and then forget about exposing/using byte_size_pretty() (that would be more consistent with the same kind of reporting in the existing code).

What do you think?

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
--------------5T6Pk0Rd4GGc1Ep4eHEdi8gC--