| 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: | Whole Thread | Raw Message | 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 |
| 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 |