Re: pg_dump bugs reported as pg_upgrade bugs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump bugs reported as pg_upgrade bugs
Date: 2022-11-30 05:22:57
Message-ID: 1276891.1669785777@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-11-30 05:42:25 Re: Strange failure on mamba
Previous Message Nathan Bossart 2022-11-30 05:18:33 Re: O(n) tasks cause lengthy startups and checkpoints