Re: pg_upgrade fails with missing FTS resources - Mailing list pgsql-bugs

From Tom Lane
Subject Re: pg_upgrade fails with missing FTS resources
Date
Msg-id 9044.1339813679@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade fails with missing FTS resources  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade fails with missing FTS resources
List pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Jun 15, 2012 at 04:15:57PM +0100, Daniele Varrazzo wrote:
>> pg_upgrade fails on missing FTS dictionaries requiring external files.
>> --check fails to detect the incompatibility.

> Sure, we can test for that.  What system column stores these file names?

Trying to check that on the basis of the system catalog entries seems
quite hopeless.  What's in the catalogs is essentially what appears
in the CREATE command, ie

dictfile = 'italian_ispell', afffile = 'italian_ispell', stopwords = 'italian_ispell'

The dictionary template knows which of these options are file names and
which are not, and what filename extension to apply to each option that
is a file name; but you don't.

The closest that I think pg_upgrade could reasonably come is to compare
the contents of the old and new installations' tsearch_data/
directories, and complain about any files present in the former and not
the latter.  However, that method seems fraught with opportunities for
false positives: in particular you might complain about some file that
was in the old installation but not actually referenced by any text
search catalog entry.

In the end I'm not sure it's worth it.  There are any number of ways
that the restore step can fail, and it's impossible for pg_upgrade
to pre-check for all of them.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade fails with missing FTS resources
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade fails with missing FTS resources