pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jonathan S. Katz <jkatz@postgresql.org>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Shruthi Gowda <gowdashru@gmail.com>
Subject: Re: pg15b2: large objects lost on upgrade
Date: Thu, 04 Aug 2022 13:49:06 -0400
Message-ID: <3573176.1659635346@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmobVx8h=1MbOPTd8ctXUG1kYUTsSidPpNrmEJbqOS+98UQ@mail.gmail.com>
References: <20220730054401.GB3644221@rfd.leadboat.com>
	<351616.1659192034@sss.pgh.pa.us>
	<635c8809-3525-7dae-a1a1-0d9069cd86bc@postgresql.org>
	<2657259.1659460333@sss.pgh.pa.us>
	<CA+TgmoastyZUAmJ6t953=yycQxu_S0x6A08QVARsbOVAWW=D2A@mail.gmail.com>
	<c07d096c-a67a-9fb9-2001-7a97b36aa5a7@postgresql.org>
	<2686054.1659469199@sss.pgh.pa.us>
	<98286e9b-8fe6-554e-c23f-d67a3df2c30d@postgresql.org>
	<2687956.1659469881@sss.pgh.pa.us>
	<CA+TgmoYqSrO-dSP6up31gv5F+1-zM-5exjKw2BU6w+FtzAzNhA@mail.gmail.com>
	<20220803202014.77m6z5m7v525p2b4@awork3.anarazel.de>
	<CA+TgmoYJaHNBghqALt-9FonK8FRB96m_MSNr9ev5EBto-2oMYw@mail.gmail.com>
	<3128525.1659559617@sss.pgh.pa.us>
	<CAH2-WzkmNN0kwPBO8t=waOCikWM4KLX9fWEYyt2oyWP08u3mSg@mail.gmail.com>
	<ddf43511-32fd-fc22-1b36-8e6c733a55b0@postgresql.org>
	<3260692.1659568781@sss.pgh.pa.us>
	<CA+TgmoZkBcMi+Nikxfc54dgkWj41Q=Z4nuyHpheTcxA-qfS5Qg@mail.gmail.com>
	<3447873.1659623176@sss.pgh.pa.us>
	<CA+TgmobVx8h=1MbOPTd8ctXUG1kYUTsSidPpNrmEJbqOS+98UQ@mail.gmail.com>

Robert Haas <robertmhaas@gmail.com> writes:
> IMHO it's 100% clear how to make it robust. If you want to check that
> two values are the same, you can't let one of them be overwritten by
> an unrelated event in the middle of the check. There are many specific
> things we could do here, a few of which I proposed in my previous
> email, but they all boil down to "don't let autovacuum screw up the
> results".

It doesn't really matter how robust a test case is, if it isn't testing
the thing you need to have tested.  So I remain unwilling to disable
autovac in a way that won't match real-world usage.

Note that the patch you proposed at [1] will not fix anything.
It turns off autovac in the new node, but the buildfarm failures
we've seen appear to be due to autovac running on the old node.
(I believe that autovac in the new node is *also* a hazard, but
it seems to be a lot less of one, presumably because of timing
considerations.)  To make it work, we'd have to shut off autovac
in the old node before starting pg_upgrade, and that would make it
unacceptably (IMHO) different from what real users will do.

Conceivably, we could move all of this processing into pg_upgrade
itself --- autovac disable/re-enable and capturing of the horizon
data --- and that would address my complaint.  I don't really want
to go there though, especially when in the final analysis IT IS
NOT A BUG if a rel's horizons advance a bit during pg_upgrade.
It's only a bug if they become inconsistent with the rel's data,
which is not what this test is testing for.

			regards, tom lane

[1] https://www.postgresql.org/message-id/CA%2BTgmoZkBcMi%2BNikxfc54dgkWj41Q%3DZ4nuyHpheTcxA-qfS5Qg%40ma...





view thread (97+ messages)  latest in thread

Message-ID: <3573176.1659635346@sss.pgh.pa.us>
Permalink:  ../3573176.1659635346@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3573176.1659635346@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, jkatz@postgresql.org, pg@bowt.ie, andres@anarazel.de, noah@leadboat.com, andrew@dunslane.net, bruce@momjian.us, michael@paquier.xyz, pryzby@telsasoft.com, gowdashru@gmail.com
  Subject: Re: pg15b2: large objects lost on upgrade
  In-Reply-To: <3573176.1659635346@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox