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 1ppyXv-0000TL-Un for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Apr 2023 21:43:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ppyXu-0001Tl-8x for pgsql-bugs@arkaria.postgresql.org; Fri, 21 Apr 2023 21:43:58 +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 1ppyXt-0001TW-Tx for pgsql-bugs@lists.postgresql.org; Fri, 21 Apr 2023 21:43:57 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ppyXn-0019PL-4i for pgsql-bugs@lists.postgresql.org; Fri, 21 Apr 2023 21:43:56 +0000 Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-24781e23c27so2320881a91.0 for ; Fri, 21 Apr 2023 14:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682113430; x=1684705430; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ELsV+14m/kPfDRPORoTmO2IsE41J4CGElmG4wnMOCp4=; b=od581VBgpMay0zIUkrAul2cD2/cheOXwVQgEMljgo65JX8GJhX9x8WEqg3bY1w6tMV /z8VgNOtJ4Ii2Wzx4eskw8G9ON1AYCpf9OY44p3L/DOwjfVp+FZ2Jz5ExGaydq6LlZKN dRbCyioYsn4wVpQQbtF+R1IGJVXkY0UaLv0FSf88zj3MEL8Cu5hhGmQkT/qhtyNCg5o2 DsmEUP1+jUfSnKO9SoCZrNtW1YpcZcTQv4fndY4d/BetNQjY0ujuzFNHlaL5vMc3A22h 8N5F/dZdWgb8N0Jjmt8cjCdQ6tZofa8IJQDJryxydtDivWDDq1883SRynzIXZYQol3Pr QHBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682113430; x=1684705430; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ELsV+14m/kPfDRPORoTmO2IsE41J4CGElmG4wnMOCp4=; b=c1ftfBJ7HanNv8dKNP7qrQGJBB9T95StfQU/vGdkfBQwFSbmHZrgkGccapwNQxuu6d lQyFZjxHQakWg7DYznxUBSfxGYa6OyjW+ZUVzIvYwgPBc6Xp9j85KTcBE+K2eOnvVwPH brQmFpqjduyJoI8/l5Tt7wu+qwi2K/0ChXuWNxh8uVYjn/TcWG+2Nu/O2NsMT/zcfEw8 t8kRzXsUHJH3j7/1YMmvA+oKS8We1L2kpLNlCqMXtXekFWPdEpahxDY5p7GyqkMlB+qA nx+O1fBZin2FNRG2EMI61gR/IO0Vml5IikHQFCHy0c3sO9S96p3xdBik0bjk83JaDUDj jc0w== X-Gm-Message-State: AAQBX9fKAoLS9haqLxJ9IzZX805dsEglrV7bWK9Um+lmoOyBv2uoUxNp P3wMdDcWSzANQKX2E/guFp8= X-Google-Smtp-Source: AKy350Z1gct/rHZgoP2f8oNGEPO7c9ZuOzPBeG3hkkJmfZZoFYpzREX/K9eoAi5nmroz23msMUeKfQ== X-Received: by 2002:a17:90b:3685:b0:23f:abfc:5acb with SMTP id mj5-20020a17090b368500b0023fabfc5acbmr6071381pjb.18.1682113430143; Fri, 21 Apr 2023 14:43:50 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id md17-20020a17090b23d100b0024744818bc5sm4981692pjb.9.2023.04.21.14.43.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Apr 2023 14:43:49 -0700 (PDT) Date: Fri, 21 Apr 2023 14:43:47 -0700 From: Nathan Bossart To: Kyotaro Horiguchi Cc: zhjwpku@gmail.com, xu.xw2008@163.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17903: There is a bug in the KeepLogSeg() Message-ID: <20230421214347.GA1441786@nathanxps13> References: <20230420.175814.1157027125103997227.horikyota.ntt@gmail.com> <20230420220242.GB1435672@nathanxps13> <20230421.104231.1594652765237022266.horikyota.ntt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230421.104231.1594652765237022266.horikyota.ntt@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Apr 21, 2023 at 10:42:31AM +0900, Kyotaro Horiguchi wrote: > From what I understand, the XLogSegNo calculations are designed > without considering the actual value range. Basically, it assumes that > (XLogSegNo + ) can overflow. If we take the actual > value range into account, we can make that change. > > The choice lies on whether we assume the actual value range or not. Yeah, after staring at this some more, I think your proposed fix is the way to go. Alternatively, we could adjust the conditional for the max_slot_wal_keep_size block to if (keep != InvalidXLogRecPtr && keep < recptr) but AFAICT that yields the exact same behavior. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com