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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jonathan S. Katz <jkatz@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
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: Tue, 02 Aug 2022 15:51:21 -0400
Message-ID: <2687956.1659469881@sss.pgh.pa.us> (raw)
In-Reply-To: <98286e9b-8fe6-554e-c23f-d67a3df2c30d@postgresql.org>
References: <YuCQQtF2p3qWs7t+@momjian.us>
	<CA+Tgmob6_NTj-euMShhcnAB_=CnkRO7-UgXVfWs4fACuDk8uAA@mail.gmail.com>
	<3901843.1659116952@sss.pgh.pa.us>
	<CA+TgmobzCRWG=_Tf0VXvF26pZbTxV-CKPNx6RdoWonKPETLvyQ@mail.gmail.com>
	<CA+TgmoYKVbB9rt2UAvaFLG-qYCgRuhAr7wPLDwTT0VpbPKvj_w@mail.gmail.com>
	<CA+TgmoZiBP2OD9POF0R2L=fib4ueOUusSVzmnO0_+kNzqSpnKw@mail.gmail.com>
	<4152163.1659124804@sss.pgh.pa.us>
	<CA+TgmoY=MfT2uc=N!4sAcHf3_teqYBNtmqVrVYv5oEK=4RfxATw@mail.gmail.com>
	<CA+TgmoZX6Zz4KU2enOYyc+aQWA+S5ZaZRGo6BgxW7mNF4btqaw@mail.gmail.com>
	<125444.1659136594@sss.pgh.pa.us>
	<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>

"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 8/2/22 3:39 PM, Tom Lane wrote:
>>> I am not in favor of disabling autovacuum in the test: ordinary
>>> users are not going to do that while pg_upgrade'ing, so it'd make
>>> the test less representative of real-world usage, which seems like
>>> a bad idea.  We could either drop this particular check again, or
>>> weaken it to allow new relfrozenxid >= old relfrozenxid, likewise
>>> relminxid.

> The test does look helpful and it would catch regressions. Loosely 
> quoting Robert on a different point upthread, we don't want to turn off 
> the alarm just because it's spuriously going off.
> I think the weakened check is OK (and possibly mimics the real-world 
> where autovacuum runs), unless you see a major drawback to it?

I also think that ">=" is a sufficient requirement.  It'd be a
bit painful to test if we had to cope with potential XID wraparound,
but we know that these installations haven't been around nearly
long enough for that, so a plain ">=" test ought to be good enough.
(Replacing the simple "eq" code with something that can handle that
doesn't look like much fun, though.)

			regards, tom lane





view thread (97+ messages)  latest in thread

Message-ID: <2687956.1659469881@sss.pgh.pa.us>
Permalink:  ../2687956.1659469881@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2687956.1659469881@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, jkatz@postgresql.org, robertmhaas@gmail.com, 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: <2687956.1659469881@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