On Mon, Apr 13, 2015 at 03:10:05PM +0000, cestel@covermymeds.com wrote:
> pg_restore: creating FUNCTION plainto_or_tsquery("text")
> pg_restore: creating FUNCTION to_weighted_tsvector("text")
> pg_restore: creating TEXT SEARCH DICTIONARY cmm_thesaurus
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 1745; 3600 60173 TEXT
> SEARCH DICTIONARY cmm_thesaurus postgres
> pg_restore: [archiver (db)] could not execute query: ERROR: could not open
> thesaurus file "/usr/pgsql-9.4/share/tsearch_data/cmm_thesaurus.ths": No
> such file or directory
> Command was: CREATE TEXT SEARCH DICTIONARY "cmm_thesaurus" (
> TEMPLATE = "pg_catalog"."thesaurus",
> dictfile = 'cmm_thesaurus', dic...
Uh, ideally pg_upgrade would be able to detect every possible case of
restore failure, but unfortunately it can't. It does look through
pg_proc and check that all shared object files referenced exist in the
new cluster. What it does not check, as you have seen, is for
dictionary files.
I looked at at how hard it would be to check for text search dictionary
files, and it looks hard. The file specification is stored in an SQL
text string:
test=> SELECT dictinitoption FROM pg_ts_dict;
dictinitoption
------------------------------------------------------------------
dictfile = 'mythesaurus', dictionary = 'pg_catalog.english_stem'
pg_upgrade would need to parse that string, then add a .ths extension to
the name, as specified here:
./backend/tsearch/dict_thesaurus.c:
filename = get_tsearch_config_filename(filename, "ths");
I don't see how this could be done easily, and yours is the first report
of this problem. I am happy that the debugging log files allowed you to
find the cause and complete the upgrade successfully.
I could document this limitation.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
