On 4/16/19 2:46 PM, Tom Lane wrote:
> Julie Nishimura <juliezain@hotmail.com> writes:
>> 1) This is the 8.3 source:
>> select * from pg_ts_dict;
>> ...
>> english_stem_nostop | 21960 | 10 | 11282 | language = 'english'
>> hwsplit | 21960 | 10 | 22342 |
>> hwsplit_only | 21960 | 10 | 22342 | returnreplaced = 'false', keeporig = 'false'
>
> OK, so you have some non-built-in text search objects in your 8.3
> installation. That's fine, but the dump/restore process should certainly
> have included commands to recreate those objects in the new database.
> Did you ignore any errors during the dump or restore? (Trying to run
> the restore as a non-superuser could well have led to failure to restore
> these objects, for instance, but you'd have gotten errors.) Did you perhaps
> do a selective dump or restore? (For example, excluding whatever schema
> 21960 is would've led to excluding these objects.)
>
> If you're not real sure about the errors angle, I'd suggest retrying
> the process to see. You could use "pg_dump -s" to dump only schema
> not data, so as to make that faster --- any relevant errors should
> still occur.
>
> I'm a bit confused by the initial report, too. If you are missing
> the text search configuration(s) your application needs, that should
> lead to query errors, not just things running slower. What exactly
> is going wrong?
>
>> Unfortunately, I am not sure about tsearch2,
>
> psql's "\dx" would tell you what extensions are installed in the
> 8.3 database.
Unfortunately that does not exist in 8.3. I think because CREATE
EXTENSION did not appear until 9.1
>
> regards, tom lane
>
--
Adrian Klaver
adrian.klaver@aklaver.com