Re: Pg_upgrade and toast tables bug discovered

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Pg_upgrade and toast tables bug discovered
Date: 2014-07-07 21:33:02
Message-ID: 20140707213302.GA11666@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 7, 2014 at 01:44:59PM -0400, Bruce Momjian wrote:
> On Mon, Jul 7, 2014 at 11:24:51AM -0400, Robert Haas wrote:
> > > As far as the reusing of oids, we don't set the oid counter until after
> > > the restore, so any new unmatched toast table would given a very low
> > > oid. Since we restore in oid order, for an oid to be assigned that was
> > > used in the old cluster, it would have to be a very early relation, so I
> > > think that reduces the odds considerably. I am not inclined to do
> > > anything more to avoid this until I see an actual error report ---
> > > trying to address it might be invasive and introduce new errors.
> >
> > That sounds pretty shaky from where I sit. I wonder if the
> > pg_upgrade_support module should have a function
> > create_toast_table_if_needed(regclass) or something like that. Or
> > maybe just create_any_missing_toast_tables(), iterating over all
> > relations.
>
> Uh, I guess we could write some code that iterates over all tables and
> finds the tables that should have TOAST tables, but don't (because
> binary-upgrade backend mode suppressed their creation), and adds them.
>
> However, that would be a lot of code and might be risky to backpatch.
> The error is so rare I am not sure it is worth it. I tried to create
> the failure case and it was very difficult, requiring me to create the
> problem table first, then some dummy stuff to get the offsets right so
> the oid would collide.
>
> Based on the rareness of the bug, I am not sure it is worth it, but if
> it is, it would be something only for 9.4 (maybe) and 9.5, not something
> to backpatch.

Another idea would be to renumber empty toast tables that conflict
during new toast table creation, when in binary upgrade mode. Since the
files are always empty in binary upgrade mode, you could just create a
new toast table, repoint the old table to use (because it didn't ask for
a specific toast table oid because it didn't need one), and then use
that one for the table that actually requested the oid. However, if one
is a heap (zero size), and one is an index (8k size), it wouldn't work
and you would have to recreate the file system file too.

That seems a lot more localized than the other approaches.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-07-07 21:37:32 Re: things I learned from working on memory allocation
Previous Message Robert Haas 2014-07-07 19:57:00 things I learned from working on memory allocation