Re: pg_upgrade and toasted pg_largeobject

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: pg_upgrade and toasted pg_largeobject
Date: 2016-05-02 21:23:58
Message-ID: 13630.1462224238@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Robert Haas wrote:
>> On Mon, May 2, 2016 at 12:30 PM, Alvaro Herrera
>> <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-05-02 21:48:18 Reviewing freeze map code
Previous Message Andres Freund 2016-05-02 21:15:43 Re: pgsql: Fix assorted inconsistencies in GIN opclass support function dec