Re: Pg_upgrade and toast tables bug discovered

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Pg_upgrade and toast tables bug discovered
Дата
Msg-id 20140707213302.GA11666@momjian.us
обсуждение исходный текст
Ответ на Re: Pg_upgrade and toast tables bug discovered  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Pg_upgrade and toast tables bug discovered  (Robert Haas <robertmhaas@gmail.com>)
Список 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: things I learned from working on memory allocation
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: things I learned from working on memory allocation