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 1o8lqU-0000BW-DX for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 16:56:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1o8lqT-0000Kf-5d for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Jul 2022 16:56:17 +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 1o8lqS-0000KQ-L8 for pgsql-hackers@lists.postgresql.org; Tue, 05 Jul 2022 16:56:16 +0000 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1o8lqK-0008Rm-Ud for pgsql-hackers@postgresql.org; Tue, 05 Jul 2022 16:56:15 +0000 Received: by mail-qt1-x832.google.com with SMTP id bs20so14551530qtb.11 for ; Tue, 05 Jul 2022 09:56:08 -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=570s8mONgntUXqUfeeyN9pY9GcY9AJMKZYhjFBIDqkE=; b=ZwxdrviI5N5h5ldnh/qf4ZnJkh/TgsNh23fymJzDCs/yezRPSgWacBsnAUixoxTyjy Ol6/s5Hm09Z/Czv6daDf3BqAkMTfxWs6PW2rz47StKzsne5ukpBMeo1wHmsaGqHtuc/e +IQjoU0xX4m0482UDq+9f1O/5sh60lpti6uk8uzfapAL24jmuWbrHP2pwiV0CWFaUKDJ nckGrUNvYVlT6EPMhlMRKK9TzwVoVfc+A6UmrJ0HfayD4e9PeiCs4EXK6ajPOxNDVBrJ +n+mwziMU0yyaGX7ZGfCY8cuq2CYlih031B4/GtUiKVOwADLgk21uGNo9k2nHWP71cxi rtXg== 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=570s8mONgntUXqUfeeyN9pY9GcY9AJMKZYhjFBIDqkE=; b=gCs1xBNCByfch8ldtQ1SKnCfFst9QhBCiMDjwdUv2Y2uxXX5DyS0IWNmt3eoMoyyDe aRaa8402/AxdcOzvcmnqoDuSOYMgC+tE7uHOybCuZqEjC5jgH+KPAJTk+53vgxqnS7oI e7m6q6G0nhAFuu7PhxbkuXekp5layiRCydfvNlHqgayKNjbTMKGUwpFiy6MiVKMA/5wR Wyc8M57Nw/rOedZIQOIjbEGGE0wFCZQE7pLw2Ywadyh7YifqUIhTTf3bxsisP76P6vhW Xp9oKU1GSPjDDUtAcu23Yeyeh2a7rYpnkKMlkYMGl3OAAuUPPC5luIxS2pM5Nvlum9Q0 d98Q== X-Gm-Message-State: AJIora9/p/XiooesxyxbDYZRPeU0Hn1X6icAYRTK+m4PPOeOahyVUe/+ EbcZfrx71uuTLpWIafwJ18SeXQ== X-Google-Smtp-Source: AGRyM1tJNR2QFRa7kjZAUHjvYauejVcnaq7tdWBvvTTJ9L5lDgJUpEQ/UVFO8Kf+vaWhxi1EklT34A== X-Received: by 2002:ac8:5a0e:0:b0:31d:3055:b6d6 with SMTP id n14-20020ac85a0e000000b0031d3055b6d6mr23272569qta.205.1657040167425; Tue, 05 Jul 2022 09:56:07 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id z3-20020a05622a124300b00316a384447fsm22863873qtx.16.2022.07.05.09.56.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jul 2022 09:56:06 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id DEB8C80086E; Tue, 5 Jul 2022 11:56:05 -0500 (CDT) Date: Tue, 5 Jul 2022 11:56:05 -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: <20220705165605.GR13040@telsasoft.com> References: <20220701231413.GI13040@telsasoft.com> <20220702154917.GM13040@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 12:43:54PM -0400, Robert Haas wrote: > On Sat, Jul 2, 2022 at 11:49 AM Justin Pryzby wrote: > > I suppose it's like Bruce said, here. > > > > https://www.postgresql.org/message-id/20210601140949.GC22012%40momjian.us > > Well, I feel dumb. I remember reading that email back when Bruce sent > it, but it seems that it slipped out of my head between then and when > I committed. I think your patch is fine, except that I think maybe we 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. > Listing the exact properties preserved seems less important to me than > mentioning that the second UPDATE statement is for its index -- +1 -- Justin