Re: pg_upgrade fails with missing FTS resources
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade fails with missing FTS resources |
Дата | |
Msg-id | 20120616023504.GB26006@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade fails with missing FTS resources (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Fri, Jun 15, 2012 at 10:27:59PM -0400, Tom Lane wrote: > 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. Agreed. Not worth it. If it is reported again, we can document this requirement. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-bugs по дате отправления: