Re: pg_upgrade and toasted pg_largeobject - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade and toasted pg_largeobject
Date
Msg-id 13630.1462224238@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade and toasted pg_largeobject  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_upgrade and toasted pg_largeobject
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Robert Haas wrote:
>> On Mon, May 2, 2016 at 12:30 PM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>>> A customer of ours was unable to pg_upgrade a database, with this error:
>>>> old and new databases "postgres" have a mismatched number of relations
>>> After some research, it turned out that pg_largeobject had acquired a
>>> toast table.

>> I think that if you use -O, and it breaks something, you get to keep
>> both pieces.

> I'm happy with the solution that pg_upgrade has a step in the check
> stage that says "catalog XYZ has a toast table but shouldn't, aborting
> the upgrade".  (Well, not _happy_, but at least it's a lot easier to
> diagnose).

I agree with Robert that this is not something we should expend a huge
amount of effort on, but I also agree that that error message is
inadequate if the situation is not a nobody-could-ever-hit-this case.

I think though that you're defining the problem too narrowly by putting
forward a solution that would result in an error message like that.
If we're going to do anything here at all, I think the code should emit
a list of the names of relations that it was unable to match up, rather
than trying (and likely failing) to be smart about why.  To take just
one reason why, the issue might be that there were too many rels in
the new installation, not too few.

The matching probably does need to be smart about toast tables to the
extent of regarding them as "toast table belonging to relation FOO",
since just printing their actual names would be unhelpful in most cases.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: old_snapshot_threshold's interaction with hash index
Next
From: Andres Freund
Date:
Subject: Reviewing freeze map code