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 1oTTKL-0003Gw-CL for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Aug 2022 19:24:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oTTKJ-0008HR-V9 for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Aug 2022 19:24:39 +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 1oTTKJ-0008HI-Jr for pgsql-hackers@lists.postgresql.org; Wed, 31 Aug 2022 19:24:39 +0000 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oTTKE-0006zc-Gz for pgsql-hackers@lists.postgresql.org; Wed, 31 Aug 2022 19:24:38 +0000 Received: by mail-pf1-x433.google.com with SMTP id l65so5021873pfl.8 for ; Wed, 31 Aug 2022 12:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=x1EPc6JNTknQmVmtFH/CMuw2D4ZZVwoJuuDTbTm0dm4=; b=PgApGbWNAp9vdXrwE3kMEvkaC+EeANZcdDJGblGkbRdD4H+dTOqAWNUKmFhE5XFz4Y efFnhCQ9CqnnzSjKscABDyiV0QYBafxy2QCWds2z5wfBQ6FvmZhgvvBsaSy3UIrl/3cD yFHM5pm8QWNG6d3t0ecUJdrG5aVM/9ArXGY7EI0xyte486XOsTKD9PBdKzOTfdkdqZjP nw0wx7O6d/Vgv605SnEW38MCALeWGI75zACnfeF3XAMaPyaNo4XhdarHiFmUx2OGVY3P uPnWKGs1RLK3fS1ObPSxIh1Xm/r25Evim72a/yLgEXlDmA5lHPLqYlgP3TwgS/95Dy/K AXTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=x1EPc6JNTknQmVmtFH/CMuw2D4ZZVwoJuuDTbTm0dm4=; b=wdEPpwfPHoJTamIiy/6kIwmz1UQ/Xy51D8KrsXAeB4uqsjLqL4dU9ZnmRJYUkrVcVe 4okyxIE9F0vcIUbrLXoI9jf0odGmAW6/lX11Gy/qT5JT7lbzzKZIucLwFGn1+Hjoh1O+ OLyqls3zcLaiCJdZyi/sZq2R9j4m5Fa4+5rPYAZ7101eDw8t8AoNLsH9rVA9FuWW9F7x F/Xw0c05VmKTqJgV7vuCEEmAHqOrmSKGFvt8xSPqnsYOymME5Jmo6wRZNClRQq1Mj2qx Q25YI2JDBqD7Gr4EFTTlA/LEsgOrrSlrtdKiL258c6hrarX5VAD303/eLKjISOT3PzP/ 6QRA== X-Gm-Message-State: ACgBeo063dYhFuPmhOSLKP59I8ncfVGHeJQVsnVNva7DKzn66S5Y5spx EL6AcuH2i85XVDXpjJ2QWIg= X-Google-Smtp-Source: AA6agR7ovLTGl51409FzheoeJFsFApvfDAHY/aJwl2BSbMhLN7PNQcN0s6TZ/lr3bgIE7cce9FYVXQ== X-Received: by 2002:a05:6a02:281:b0:42b:748e:5d90 with SMTP id bk1-20020a056a02028100b0042b748e5d90mr21962764pgb.422.1661973872435; Wed, 31 Aug 2022 12:24:32 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id a1-20020a170902ecc100b0016d93c84049sm8390499plh.54.2022.08.31.12.24.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Aug 2022 12:24:31 -0700 (PDT) Date: Wed, 31 Aug 2022 12:24:28 -0700 From: Nathan Bossart To: Andres Freund Cc: Bharath Rupireddy , Michael Paquier , Thomas Munro , Tom Lane , "Bossart, Nathan" , Julien Rouhaud , PostgreSQL Hackers Subject: Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work Message-ID: <20220831192428.GA641777@nathanxps13> References: <20220816203233.GA255076@nathanxps13> <20220823180744.GD1207981@nathanxps13> <20220831191433.ruqbhu2ady4qrdpv@awork3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220831191433.ruqbhu2ady4qrdpv@awork3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Aug 31, 2022 at 12:14:33PM -0700, Andres Freund wrote: > On 2022-08-27 14:06:32 +0530, Bharath Rupireddy wrote: >> - if (lstat(fromfile, &fst) < 0) >> - ereport(ERROR, >> - (errcode_for_file_access(), >> - errmsg("could not stat file \"%s\": %m", fromfile))); >> + xlde_type = get_dirent_type(fromfile, xlde, false, ERROR); >> >> - if (S_ISDIR(fst.st_mode)) >> + if (xlde_type == PGFILETYPE_DIR) >> { >> /* recurse to handle subdirectories */ >> if (recurse) >> copydir(fromfile, tofile, true); >> } >> - else if (S_ISREG(fst.st_mode)) >> + else if (xlde_type == PGFILETYPE_REG) >> copy_file(fromfile, tofile); >> } >> FreeDir(xldir); > > It continues to make no sense to me to add behaviour changes around > error-handling as part of a conversion to get_dirent_type(). I don't at all > understand why e.g. the above change to make copydir() silently skip over > files it can't stat is ok? In this example, the call to get_dirent_type() should ERROR if the call to lstat() fails (the "elevel" argument is set to ERROR). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com