Re: BUG #13042: pg_upgrade --check succeeded but run failed due to missing thesaurus file - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #13042: pg_upgrade --check succeeded but run failed due to missing thesaurus file
Date
Msg-id 20150417013547.GA1868@momjian.us
Whole thread Raw
In response to Re: BUG #13042: pg_upgrade --check succeeded but run failed due to missing thesaurus file  (CJ Estel <CEstel@covermymeds.com>)
List pgsql-bugs
On Thu, Apr 16, 2015 at 02:23:54PM +0000, CJ Estel wrote:
> Thanks for looking into this.  Updating the documentation would be great.
> If it is easy to throw a warning message that thesauri were found and
> should be copied to the new location that would help people as well, even
> if it doesn't do the actual check for the existence of the files.

I have developed the attached documentation patch that I have applied to
head and 9.4.

I looked into issuing some kind of warning from pg_upgrade, but it is
hard to do.  Not only can you have thesaurus files, but also
dictionaries, synonyms, and stop word files.  pg_upgrade would have to
know how to parse the pg_ts_dict.dictinitoption string, pick out each of
these, know the expected file extension, and check for its existence ---
That seems too invasive for pg_upgrade to do.

One idea would be to write a server-side function that parses that field
and returns all referenced file names, and pg_upgrade can call that on
the old server then check those on the new server.  I am not sure it is
worth it, but if someone writes it, I can have pg_upgrade use it.  The
big problem there is that you have to run that function on the old
server, so it is hard to see how that will help with a 9.5 upgrade ---
it would only work for upgrades where 9.5 is the _old_ version.   Also,
we don't  have any easy way to backpatch system catalog changes like
adding a new function.

Another idea I had was to do a directory listing of old cluster's
share/tsearch_data and compare that to the new server, but if we ever
add files to share/tsearch_data in a major release, pg_upgrade would
fail with no way for users to fix it, so that seems bad.

Anyway, the doc fix is there and if anyone has better ideas, I am all
ears.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Attachment

pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #13073: Uniqueness constraint incorrectly reports constraint violations
Next
From: Oskari Saarenmaa
Date:
Subject: Re: BUG #8470: 9.3 locking/subtransaction performance regression