Re: pg_migrator issue with contrib - Mailing list pgsql-hackers

Bruce Momjian <bruce@momjian.us> writes:
> I think the cleanest solution is to document that these issues might
> happen and suggest solutions.

No, the cleanest solution is to fix it before people ever see a
problem.  This is trivial to do in the case of dblink and I don't
see why you think it would be better to make users work around it.

Also, dblink is one of the easiest cases because (a) it doesn't have
anything but functions, and thus it's possible to drop it from the
old DB without data loss, and (b) the inconsistency that it has is
something that will result in a clean, readily understandable failure
during migration.  As opposed to some other cases that will migrate
just fine and then dump core during use.

I've just finished running through a diff of 8.3 vs 8.4 contrib
SQL files.  It looks like we have these cases:

* Quite a few modules have differences in the signatures of GIST and
GIN opclass support functions.  As was discussed earlier, we don't
really have to fix those, because the SQL-level signatures don't
affect anything at runtime.  Most of these modules also have RECHECK
flags that were removed, but we have a solution for that too.

* dblink has an entirely unnecessary change in the definition of
dblink_current_query(), which will cause it to fail to migrate.

* fuzzystrmatch has added a new levenshtein() function.  The worst
case if this is migrated without any extra effort is the user
doesn't have access to that function.  But it's a functions-only
module, so the user could fix it by just rerunning the SQL file
afterwards.

* intarray has removed its internal @> and <@ operators.  As I was
mentioning the other day, it might be the best thing to just revert
that change anyway, until we can get a better handle on the behavior
of GIN for empty arrays.

* isn has got the nastiest problems of the lot: since it piggybacks
on type bigint, a migrated database might work, or might crash
miserably, depending on whether bigint has become pass-by-value
in the new database.  I'm not very sure if we can fix this reasonably.

* pageinspect has changed the ABI of get_raw_page() in a way that will
likely make it dump core if the function definition is migrated from
an old DB.  This needs to be fixed.  It's also added a new function
fsm_page_contents(bytea), which is no big problem, since the SQL
file can be re-executed without harm.

* pg_buffercache has changed the view pg_buffercache, which is
definitely going to be a migration issue.  Need to test whether
it represents a crash risk if the old definition is migrated.

* pg_freespacemap has made *major* changes in its ABI.  There's
probably no hope of this working either, but we need to be sure
it's not a crash risk.

* pgstattuple has made changes in the output types of its functions.
This is a serious crash risk, and I'm not immediately sure how to
fix it.  Note that simply migrating the module will not draw any
errors.

* seg has added a new function seg_center(seg).  This can be fixed
by reloading the SQL file, but not by dropping the module beforehand
since that would risk data loss.

* tsearch2 has opclass support function changes, but unlike other
cases of this, it will fail to migrate to 8.4 because the functions
are references to core functions instead of being declared in the
module.  Also, "drop it first" isn't a very useful recommendation
since the domains it defines might be used somewhere.

So we've definitely got some work here.  If we do nothing, several
of these issues are going to end up with CVE numbers.
        regards, tom lane