Re: pg_dump bugs reported as pg_upgrade bugs - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_dump bugs reported as pg_upgrade bugs
Date
Msg-id Y4dgwly/Vwfw4iAT@momjian.us
Whole thread Raw
In response to Re: pg_dump bugs reported as pg_upgrade bugs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Nov 30, 2022 at 12:22:57AM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > FYI, you might wonder why so many bugs reported on pg_upgrade eventually
> > are bugs in pg_dump.  Well, of course, partly is it because pg_upgrade
> > relies on pg_dump, but a bigger issue is that pg_upgrade will fail if
> > pg_dump or its restoration generate _any_ errors.  My guess is that many
> > people are using pg_dump and restore and just ignoring errors or fixing
> > them later, while this is not possible when using pg_upgrade.
> 
> pg_dump scripts are *designed* to be tolerant of errors, mainly so
> that you can restore into a situation that's not exactly like where
> you dumped from, with the possible need to resolve errors or decide
> that they're not problems.  So your depiction of what happens in
> dump/restore is not showing a problem; it's about using those tools
> as they were intended to be used.
> 
> Indeed, there's a bit of disconnect there with pg_upgrade, which would
> like to present a zero-user-involvement, nothing-to-see-here facade.

Agreed, a disconnect, plus if it is a table or index restore that fails,
pg_upgrade would fail later because there would be no system catalogs to
move the data into.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

Embrace your flaws.  They make you human, rather than perfect,
which you will never be.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: New docs chapter on Transaction Management and related changes
Next
From: "David G. Johnston"
Date:
Subject: Re: New docs chapter on Transaction Management and related changes