| Time |
Nick |
Message |
| 07:11 |
|
collum joined #evergreen |
| 07:16 |
|
_collum joined #evergreen |
| 07:21 |
|
rjackson_isl_hom joined #evergreen |
| 08:24 |
|
mantis1 joined #evergreen |
| 08:33 |
|
rjackson_isl_hom joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 08:55 |
|
jvwoolf joined #evergreen |
| 10:36 |
|
Stompro joined #evergreen |
| 10:58 |
|
RFrasur joined #evergreen |
| 11:00 |
Bmagic |
I'm testing an upgrade to PG 10. Performing pg_dump, then pg_restore on pg10. I'm pre-creating the database on PG10 following the Evergreen create database extension file "create_database_extensions.sql" - That setup does not call for tsearch2, which was removed back in EG2.4. When I restore my dumped database, I get errors about missing tsearch2 |
| 11:00 |
Bmagic |
ERROR: could not open extension control file "/usr/share/postgresql/10/extension/tsearch2.control": No such file or directory |
| 11:01 |
Bmagic |
Command was: CREATE EXTENSION IF NOT EXISTS tsearch2 WITH SCHEMA public; |
| 11:02 |
Bmagic |
I found this patch bug 1175287 which was part of db upgrade 0743. which was* ran on this db according to config.upgrade_log. But maybe I'm barking up the wrong tree |
| 11:02 |
pinesol |
Launchpad bug 1175287 in Evergreen "2.3-2.4 upgrade: drop tsearch2 extension only if it exists" [Medium,Fix released] https://launchpad.net/bugs/1175287 |
| 11:04 |
Dyrcona |
Bmagic: You don't have to create the database prior to restoring a dump file. |
| 11:04 |
Bmagic |
pg_dump -Fd -Z 0 -f /mnt/pgdump/96dump --serializable-deferrable evergreen |
| 11:05 |
Dyrcona |
pg_dump evergreen -U evergreen -Fc > $ARCHIVE_FILE |
| 11:06 |
Dyrcona |
/usr/lib/postgresql/${VERSION}/bin/pg_restore -U evergreen -h localhost \ |
| 11:06 |
Dyrcona |
-p ${PORT} -C -c -d postgres -j ${JVAL} ${dumpfile} |
| 11:06 |
Bmagic |
at some point (like 2013ish) - I was taught to use the serializable-deferrable dump method for Evergreen. It was said that it was "better" somehow |
| 11:07 |
Dyrcona |
You also need to make sure that you are using the version of pg_restore for the database that you are restoring into. |
| 11:09 |
Bmagic |
so, my method is not correct? Or rather, would not be the correct approach to get Evergreen to pg10? |
| 11:09 |
Dyrcona |
Not saying that your method is incorrect. Just pasting what I do. |
| 11:10 |
Dyrcona |
The above is restored on a weekly basis, and yes, it is probably safer to use --serializable-deferrable. |
| 11:10 |
Bmagic |
I see. I'm using the method that I used from pg 9.3->9.4 and used it for 9.4->9.5 and again 9.5->9.6. And here we are |
| 11:11 |
Dyrcona |
There's not point in using the Evergreen create schema scripts. The dump is going to overwrite it. |
| 11:11 |
Bmagic |
I have a foggy memory of this tsearch2 issue before, but I think I ignored it |
| 11:12 |
Dyrcona |
If you're sure that you no longer need tsearch2, then you can drop the extension before dumping. You may have some custom or old stuff hanging around that uses it. |
| 11:15 |
Bmagic |
that's where I started, and found that I couldn't drop it without dropping metabib.combined_subject_field_entry column index_vector and familty. Then started researching that column to find that the table has index_vectore set to "public.tsvector" and it seems that it needs to be plain ol' "tsvector" |
| 11:16 |
* Dyrcona |
checks something. |
| 11:16 |
Bmagic |
because it's referencing public.tsvector.... So maybe I just drop those tables and indexes and re-create them, and reingest? |
| 11:18 |
Dyrcona |
My guess is that you ran 0743, but it failed and the versions number ended up in config.upgrade_log anyway. |
| 11:18 |
Bmagic |
because those columns would have come out as tsvector instead of public.tsvector? |
| 11:23 |
Dyrcona |
Bmagic: AFAICT, tsearch2 is gone/not available for Pg 10, so you'll have to resolve that before you can upgrade. |
| 11:24 |
Bmagic |
gotcha, I think I need to recreate those metabib tables |
| 11:24 |
Dyrcona |
The reason I say that it looks like the db upgrade failed is because tsearch2 is still present because columns depend on it. |
| 11:25 |
Dyrcona |
You may have had something out of sync with the base schema when that upgrade was run, so columns weren't dropped properly, but the whole db upgrade should have failed at that point. |
| 11:29 |
Bmagic |
I agree. Not sure what went on. But I think* dropping those tables is "safe" because they can be repopulated with reingest? |
| 11:29 |
Dyrcona |
Yes, it should be ok to drop and recreate the tables. |
| 11:32 |
Dyrcona |
You could try altering the table columns. That would be less dangerous/destructive. |
| 11:35 |
Dyrcona |
It looks like tsearch2 was removed from postgresql contrib in Pg 8.3, which means it became a regular feature around that time. With Pg 10, the contrib package has been dropped and the extensions are part of the regular distribution. |
| 11:38 |
Dyrcona |
tsearch2 is definitely not present for Pg 10. I don't have a Pg 9.6 database handy to check if it exists there. |
| 12:00 |
|
jihpringle joined #evergreen |
| 14:55 |
|
rjackson_isl_hom joined #evergreen |
| 16:06 |
|
jihpringle joined #evergreen |
| 16:12 |
Dyrcona |
Trying to find patrons with over 80 circulations and this happened: SSL SYSCALL error: Connection timed out |
| 16:15 |
|
jvwoolf left #evergreen |
| 16:18 |
Bmagic |
That's "fun" |
| 16:24 |
Dyrcona |
Well, I reconnected and ran a query with a lower having and it returned pretty quickly, so I bumped it back up to 80 and got some accounts to test with. |
| 17:17 |
|
mmorgan left #evergreen |
| 17:24 |
|
jihpringle joined #evergreen |
| 17:30 |
|
Christineb joined #evergreen |
| 17:49 |
|
rjackson_isl_hom joined #evergreen |
| 20:00 |
|
troy joined #evergreen |
| 20:00 |
|
bshum joined #evergreen |
| 23:59 |
|
StomproJ joined #evergreen |
