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 1o93da-0005LP-0l for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Jul 2022 11:56:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o93dY-0004gg-Sz for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Jul 2022 11:56:08 +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 1o93dY-0004gW-Gb for pgsql-hackers@lists.postgresql.org; Wed, 06 Jul 2022 11:56:08 +0000 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o93dU-0006Zd-6J for pgsql-hackers@postgresql.org; Wed, 06 Jul 2022 11:56:07 +0000 Received: by mail-qt1-x832.google.com with SMTP id l14so17809134qtx.2 for ; Wed, 06 Jul 2022 04:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=WxHLTozkkcq3VTxqHAr4lV+F2QJwOyFF6acld4j+laA=; b=FEWDlRTGn/w/bDeMvr54dDc0f42E3D6ghEMKvo2x95VmQZ9ij2DvHvk+HOY3axmGTb kQAPp2+w13B05+M/JRhrS6f8YuY2ie52OLCfW6xU2m4lB7Ou+eyz3Y1cndtVQjJtyDUQ PMvWNnmDzwvCMG5LVh/9WF1lmczQQ7h6cB/Z4CQ62R/3IvbVJKjKybRwYUsKDo28t2Wn gU8zYHcFARUpyjBye9YD1V4kqkGbe7RfrmC4mqhehJCwXgUpLg9/ma1BE1yVjS+yZ2/l Cn+E+gqVAuv901BjQZhruEFwPnw6X2nSrWf3+8Fh4xpvo9efdQQS8MgMhOX2oNxJm5Ah iKew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=WxHLTozkkcq3VTxqHAr4lV+F2QJwOyFF6acld4j+laA=; b=01egrlMRMJz7Sb7Ch9VfHtKsJUotqVM8tByY/DOge9GYezaVzKSL8X7gqRsfONsaA7 WN1P6QhqXk5ZtW0VDC5JM+ptq+CIUwy0iHf3P6veaKjyne6Jhv7yDjeKrP/ram2fXxLJ Yr5iN3tKs6+3XQVZ5xKk/NpreZrRA7N9O9JChvfCT8bgyXAyO/N/6Gh8ZbCHHF0YztLn 484MF9foZOJKFyVs35/0/q5NtaBFHs1kWDVE9pZKna/H0pFtCjSOUjEcPJiZawULgEI9 eGe6AqShMLXRP0PlcAIuKu8K77nCmXKSTFxkFNHmjM8IObjJzgVtKX5KvioCbzn+lmem TyBg== X-Gm-Message-State: AJIora9Mr4J27VaWfTHbWaTyuaItc5cMNHZCeIB7FGUj2uJ1NWYTe+MF eh3UnMP47ztF2GxFFHL95dmBNw== X-Google-Smtp-Source: AGRyM1tbyNsrgNXwMCqcTiFEvKMKwY9emNl5UtWbVJUwLnziHdwxwbpKVWzi3TJcBP5nZ5iWksDLyQ== X-Received: by 2002:a05:6214:29ec:b0:470:5aec:e15e with SMTP id jv12-20020a05621429ec00b004705aece15emr36525677qvb.102.1657108561951; Wed, 06 Jul 2022 04:56:01 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id o23-20020ac84297000000b0031871343473sm22571193qtl.83.2022.07.06.04.56.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2022 04:56:01 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id CB35980066A; Wed, 6 Jul 2022 06:56:00 -0500 (CDT) Date: Wed, 6 Jul 2022 06:56:00 -0500 From: Justin Pryzby To: Robert Haas Cc: pgsql-hackers@postgresql.org, Bruce Momjian , Shruthi Gowda Subject: Re: pg15b2: large objects lost on upgrade Message-ID: <20220706115600.GU13040@telsasoft.com> References: <20220701231413.GI13040@telsasoft.com> <20220702154917.GM13040@telsasoft.com> <20220705165605.GR13040@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jul 05, 2022 at 02:40:21PM -0400, Robert Haas wrote: > On Tue, Jul 5, 2022 at 12:56 PM Justin Pryzby wrote: > > My patch also leaves a 0 byte file around from initdb, which is harmless, but > > dirty. > > > > I've seen before where a bunch of 0 byte files are abandoned in an > > otherwise-empty tablespace, with no associated relation, and I have to "rm" > > them to be able to drop the tablespace. Maybe that's a known issue, maybe it's > > due to crashes or other edge case, maybe it's of no consequence, and maybe it's > > already been fixed or being fixed already. But it'd be nice to avoid another > > way to have a 0 byte files - especially ones named with system OIDs. > > Do you want to add something to the patch to have pg_upgrade remove > the stray file? I'm looking into it, but it'd help to hear suggestions about where to put it. My current ideas aren't very good. -- Justin