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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: CJ Estel <CEstel(at)covermymeds(dot)com>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13042: pg_upgrade --check succeeded but run failed due to missing thesaurus file
Date: 2015-04-17 01:35:47
Message-ID: 20150417013547.GA1868@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Attachment Content-Type Size
pg_upgrade.diff text/x-diff 677 bytes

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message digoal 2015-04-17 03:58:56 BUG #13077: when standby crash and restart, it's need next timeline history file, but upstream node normal.
Previous Message David G. Johnston 2015-04-16 22:46:06 Re: BUG #13073: Uniqueness constraint incorrectly reports constraint violations