2009-08-10T04:03:34 *** ben-ct has joined #OpenILS-Evergreen 2009-08-10T07:57:03 *** kgs has joined #openils-evergreen 2009-08-10T08:05:06 *** gmcharlt has quit IRC 2009-08-10T08:08:56 *** mck9 has joined #openils-evergreen 2009-08-10T08:24:36 *** mrpeters-isl has joined #openils-evergreen 2009-08-10T08:25:09 *** gmcharlt has joined #OpenILS-Evergreen 2009-08-10T08:41:15 mrpeters-isl pasted "autogen.sh 1.4 errors" at http://paste.lisp.org/display/85121 2009-08-10T08:41:27 anyone have any tips on the above autogen.sh errors? 2009-08-10T08:41:30 with 1.4.0.4 2009-08-10T08:44:09 *** kbeswick has joined #openils-evergreen 2009-08-10T09:12:51 *** jenny has joined #OpenILS-Evergreen 2009-08-10T09:21:00 mrpeters-isl annotated #85121 "osrfsys.log" at http://paste.lisp.org/display/85121#1 2009-08-10T09:31:42 berick: you there? 2009-08-10T09:37:03 *** ben-ct has joined #OpenILS-Evergreen 2009-08-10T09:39:35 mrpeters-isl: check your upgrade/install scripts as they relate to the locale configs in the database... 2009-08-10T09:39:38 mrpeters-isl: open-ils.cstore 2009-08-10 08:39:29 [ERR :17683:oils_cstore.c:2669:] open-ils.cstore: Error retrieving config::i18n_locale 2009-08-10T09:40:55 jeff: which upgarde/install scripts? im not quite sure what you mean by that 2009-08-10T09:43:25 kbeswick: in and out, feel free to ask me whatever 2009-08-10T09:46:26 mrpeters-isl: on the installation in question, was the database upgraded from a previous version, or a clean install? if a previous version, which version? 2009-08-10T09:46:32 jeff: 1.2.3-1.4-upgrade-db.sql should have created config.i18n_locale but it appears it did not...i guess ill try to run it again 2009-08-10T09:46:39 mrpeters-isl: do you have a config.i18n_locale table in the database? 2009-08-10T09:46:48 mrpeters-isl: okay, yep... you're on the right path. 2009-08-10T09:46:51 jeff: nope, see above 2009-08-10T09:47:13 mrpeters-isl: if you have logged the output from when you ran that script, you might look for errors there. 2009-08-10T09:47:29 jeff: yes, see here 2009-08-10T09:47:47 mrpeters-isl annotated #85121 "upgrade .sql errors" at http://paste.lisp.org/display/85121#2 2009-08-10T09:49:32 mrpeters-isl: can you annotate that with the current output of \d config.language_map 2009-08-10T09:49:38 sure 2009-08-10T09:50:12 mrpeters-isl annotated #85121 "\d config.language_map" at http://paste.lisp.org/display/85121#3 2009-08-10T09:50:17 done 2009-08-10T09:50:38 okay, you're missing a primary key. one sec. 2009-08-10T09:50:46 ok! 2009-08-10T09:55:01 okay, that's very unusual. 2009-08-10T09:55:20 config.language_map according to svn has never NOT had a primary key defined. 2009-08-10T09:55:31 hmm 2009-08-10T09:55:53 config.language_map wouldnt be in a 1.2.3.1 database, right? 2009-08-10T09:55:55 mrpeters-isl: what's the lineage of the database? what version of evergreen was it originally created under? 2009-08-10T09:56:09 (way back when) 2009-08-10T09:56:11 this is a 1.2.3.1 database then i followed http://open-ils.org/dokuwiki/doku.php?id=upgrading:1.2_to_1.4.0:latest_version_of_evergreen 2009-08-10T09:57:13 weird...our production has Indexes: "language_map_pkey" PRIMARY KEY, btree (code) 2009-08-10T09:57:18 i wonder why that was lost? 2009-08-10T09:57:24 mrpeters-isl: 1.2.3.1 should have a config.language_map defined with a primary key. see http://svn.open-ils.org/trac/ILS/browser/tags/rel_1_2_3_1/Open-ILS/src/sql/Pg/002.schema.config.sql 2009-08-10T09:57:37 yep, it sure does 2009-08-10T09:57:43 mrpeters-isl: no idea. possibly some other upgrade/maint. attempt failed due to a duplicate key and it was manually removed? 2009-08-10T09:57:53 im not sure 2009-08-10T09:57:56 how best to repair? 2009-08-10T09:58:46 just run that 002.schema.config.sql? 2009-08-10T09:58:48 one sec. this is dev -- a trial run, not something you're hoping to move into production once you get it working? 2009-08-10T09:58:52 mrpeters-isl: i wouldn't run that, no. 2009-08-10T09:59:10 jeff: yes, its just a trial going from 1.2.3.1 to 1.4.0.4 and then to trunk 2009-08-10T09:59:31 so we can get our trainers a head start working on 1.6 documentation 2009-08-10T10:02:12 mrpeters-isl: you should be able to use this: ALTER TABLE config.language_map ADD PRIMARY KEY (code); 2009-08-10T10:02:48 ok 2009-08-10T10:02:52 that seemed to work 2009-08-10T10:03:54 and now, psql:Open-ILS/src/sql/Pg/1.2.3-1.4-upgrade-db.sql:114: ERROR: constraint "xml_transform_namespace_uri_key" does not exist 2009-08-10T10:04:01 i bet all of these primary keys are broken 2009-08-10T10:05:26 mrpeters-isl: that xml_transform_namespace_uri_key error is fine. 2009-08-10T10:05:36 mrpeters-isl: the upgrade script attempts to drop that constraint. 2009-08-10T10:05:45 ok 2009-08-10T10:05:47 mrpeters-isl: so, last time it dropped it, and now it can't find it this time. 2009-08-10T10:05:58 it stops after that, so does that assume all else worked? 2009-08-10T10:06:05 mrpeters-isl: fyi, i have no idea if the upgrade scripts are ever intended to be safe to run multiple times. 2009-08-10T10:06:14 yeah, probably not haha 2009-08-10T10:06:34 mrpeters-isl: i was going to have you re-run the stuff just related to the missing table. :) 2009-08-10T10:06:44 mrpeters-isl: but barring other huge errors, give it another try now. 2009-08-10T10:06:58 jeff: autogen still fails :( 2009-08-10T10:07:17 (just make a note that you ran the upgrade script twice, should other oddness come up and be explained by that) 2009-08-10T10:07:24 mrpeters-isl: different errors this time, i hope? 2009-08-10T10:07:32 sadly, no 2009-08-10T10:07:47 mrpeters-isl annotated #85121 "autogen.sh" at http://paste.lisp.org/display/85121#4 2009-08-10T10:08:36 mrpeters-isl annotated #85121 "messy paste" at http://paste.lisp.org/display/85121#5 2009-08-10T10:08:43 mrpeters-isl: two things... that most recent paste seems to be missing some characters... ah, you caught it. 2009-08-10T10:08:45 previouis paste was hard to read...thats cleaner 2009-08-10T10:08:58 and second, can you get the osrfsys.log entries relating to this most recent set of errors? 2009-08-10T10:09:03 you sure can 2009-08-10T10:09:10 or, i sure can, haha 2009-08-10T10:09:48 mrpeters-isl annotated #85121 "osrfsys.log 2" at http://paste.lisp.org/display/85121#6 2009-08-10T10:10:30 the big problem seems to be that same SELECT "i18n_l".code, "i18n_l".marc_code, oils_i18n_xlate('config.i18n_locale', 'i18n_l', 'name', 'code', "i18n_l".code::TEXT, 'en-US') AS "name", oils_i18n_xlate('config.i18n_locale', 'i18n_l', 'description', 'code', "i18n_l".code::TEXT, 'en-US') AS "description" FROM config.i18n_locale AS "i18n_l" WHERE "i18n_l".code IS NOT NULL ORDER BY name; 2009-08-10T10:10:39 which gives ERROR: relation "config.i18n_locale" does not exist in my db 2009-08-10T10:11:03 mrpeters-isl: can you confirm that config.i18n_locale table exists? 2009-08-10T10:11:06 ah. 2009-08-10T10:11:11 yeah, it doesnt 2009-08-10T10:11:12 well, that's... interesting. 2009-08-10T10:11:13 oh. 2009-08-10T10:11:16 *** brendan_ga has quit IRC 2009-08-10T10:11:49 mrpeters-isl: your attempt to run the upgrade script twice failed on that constraint that had already been dropped... and the upgrade scripts set \set ON_ERROR_STOP 1 2009-08-10T10:12:09 mrpeters-isl: so your most recent upgrade script run stopped there and never went on to create the config.i18n_locale table. 2009-08-10T10:12:15 ahhh yeah and i see where it would have done CREATE TABLE config.i18n_locale 2009-08-10T10:12:22 yep, how can i tweak that to kee going? 2009-08-10T10:12:32 mrpeters-isl: one sec. 2009-08-10T10:13:35 mrpeters-isl: i would try this... make a copy of the upgrade script, and remove the lines after \set ON_ERROR_STOP 1 until you get to CREATE TABLE config.i18n_locale 2009-08-10T10:13:49 mrpeters-isl: because that create table statement is where it errored out on your first attempt. 2009-08-10T10:13:57 ok 2009-08-10T10:14:31 once you've removed the lines that have already been done, you should run the script, and see how far you get this time. :) 2009-08-10T10:14:39 *** meliss has joined #OpenILS-Evergreen 2009-08-10T10:15:36 psql:Open-ILS/src/sql/Pg/1.2.3-1.4-upgrade-db.sql:25: ERROR: relation "i18n_locale" already exists 2009-08-10T10:17:00 mrpeters-isl annotated #85121 "\d config.i18n_locale" at http://paste.lisp.org/display/85121#7 2009-08-10T10:17:02 *** sboyette has joined #openils-evergreen 2009-08-10T10:17:13 *** sboyette has quit IRC 2009-08-10T10:17:19 mrpeters-isl: i'm sorry, i had you delete too many lines from that upgrade script (for one thing) 2009-08-10T10:17:27 uh oh :) 2009-08-10T10:17:37 (should've backed up) 2009-08-10T10:17:42 heh 2009-08-10T10:17:47 i SAID to make a copy :) 2009-08-10T10:17:53 haha i have a copy 2009-08-10T10:17:57 just have to scp it over 2009-08-10T10:18:17 *** sboyette has joined #openils-evergreen 2009-08-10T10:18:48 mrpeters-isl: one moment. 2009-08-10T10:18:58 ok 2009-08-10T10:20:01 mrpeters-isl: can you paste a \d config.metabib_field 2009-08-10T10:20:42 *** rschiffman has joined #openils-evergreen 2009-08-10T10:21:02 mrpeters-isl annotated #85121 "\d config.metabib_field" at http://paste.lisp.org/display/85121#8 2009-08-10T10:21:17 mrpeters-isl: okay. thanks. 2009-08-10T10:21:28 no, thank yo 2009-08-10T10:22:30 btw, back to the original upgrade .sql so i can remove the right amount this time....whatever that is 2009-08-10T10:23:27 yeah. the hard part is that script isn't meant to be run more than once. when it breaks part way through, it's messy. :) 2009-08-10T10:23:34 sure 2009-08-10T10:23:56 my apologies 2009-08-10T10:24:19 mrpeters-isl: do you get any data with SELECT * from config.upgrade_log; -- please pastebin that output if any. 2009-08-10T10:24:33 ERROR: relation "config.upgrade_log" does not exist 2009-08-10T10:24:50 mrpeters-isl: not your fault. we'd be in this boat even if you hadn't run it the second time... because we'd still need to get through the parts that were skipped the first time. 2009-08-10T10:25:02 ok 2009-08-10T10:25:04 *** rschiffman has quit IRC 2009-08-10T10:25:52 it almost seems like it got nowhere, since i have nothing in config.upgrade_log and thats one of the first things that happens 2009-08-10T10:26:22 but then, config.i18n_locale did get created 2009-08-10T10:26:32 mrpeters-isl: yeah, it does it all within a transaction, so some of it gets rolled back when it fails. some things can't be rolled back, though. 2009-08-10T10:26:42 ah ok 2009-08-10T10:28:19 mrpeters-isl: one option would be to drop this database, load the snapshot that you're working from, fix the original primary key missing on language_map issue, and try running the upgrade script "fresh" 2009-08-10T10:28:31 yeah, i will do that 2009-08-10T10:28:48 mrpeters-isl: the other option is to walk through the upgrade script chunk by chunk and determine what's already been done and what's not. :) 2009-08-10T10:28:59 mrpeters-isl: good plan! ;-) 2009-08-10T10:29:02 yeah ill try a fresh one first 2009-08-10T10:33:53 jeff: just to clairify, you want me to do "ALTER TABLE config.language_map ADD PRIMARY KEY (code);" again after a restore 2009-08-10T10:33:59 then try the upgrade script again and see where we fail 2009-08-10T10:34:04 *** brendan_ga has joined #OpenILS-Evergreen 2009-08-10T10:45:34 *** rschiffman_ has joined #openils-evergreen 2009-08-10T10:57:17 mrpeters-isl: yes, assuming that the primary key isn't there after the restore, add it, then run the upgrade script. 2009-08-10T10:57:27 10-4 2009-08-10T10:57:47 mrpeters-isl: since we don't know where the primary key on config.language_map went missing, it might not need to be re-added. 2009-08-10T10:58:03 true, i will check first! 2009-08-10T10:58:17 pgrestore will take a while, however, haha so i wont be able to report for a bit 2009-08-10T11:00:06 *** phasefx has quit IRC 2009-08-10T11:09:06 mrpeters-isl: good luck! 2009-08-10T12:04:12 *** brendan_ga has quit IRC 2009-08-10T12:04:12 *** mck9 has quit IRC 2009-08-10T12:04:12 *** _bott_ has quit IRC 2009-08-10T12:04:12 *** asmodai has quit IRC 2009-08-10T12:07:47 *** asmodai has joined #OpenILS-Evergreen 2009-08-10T12:11:25 *** brendan_ga has joined #openils-evergreen 2009-08-10T12:11:25 *** mck9 has joined #openils-evergreen 2009-08-10T12:11:25 *** _bott_ has joined #openils-evergreen 2009-08-10T12:16:50 *** sarabee_ has quit IRC 2009-08-10T12:16:50 *** phasefx2 has quit IRC 2009-08-10T12:17:07 *** sarabee_ has joined #openils-evergreen 2009-08-10T12:17:07 *** phasefx2 has joined #openils-evergreen 2009-08-10T12:31:29 *** mrpeters-isl has quit IRC 2009-08-10T12:32:41 *** mrpeters-isl has joined #openils-evergreen 2009-08-10T13:31:30 *** jenny has quit IRC 2009-08-10T13:52:50 *** jenny has joined #OpenILS-Evergreen 2009-08-10T14:01:33 *** sarabee_ has quit IRC 2009-08-10T14:06:18 *** sarabee has joined #openils-evergreen 2009-08-10T14:30:53 jeff: on restore, that pkey was there (weird!) 2009-08-10T14:31:02 and upgrade seems to be going well (got much futher than before so far) 2009-08-10T14:41:50 jeff: around? 2009-08-10T14:44:07 around. 2009-08-10T14:45:55 jeff....crapped out on me again, because i had dupe shelving locations....got those fixed and im now going to delete all in the sql up to the point it went bad and run again 2009-08-10T14:51:43 mrpeters-isl: careful. one sec... 2009-08-10T14:51:51 ok 2009-08-10T14:52:03 psql:Open-ILS/src/sql/Pg/1.2.3-1.4-upgrade-db.sql:485: NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index "acl_name_once_per_lib" for table "copy_location" psql:Open-ILS/src/sql/Pg/1.2.3-1.4-upgrade-db.sql:485: ERROR: could not create unique index 2009-08-10T14:52:06 thats where it left off 2009-08-10T14:52:37 mrpeters-isl: earlier i had you delete too much... i had you delete after the \set ON_ERROR_STOP 1 line... don't do that again :) 2009-08-10T14:52:48 ok 2009-08-10T14:52:51 where should i delete? 2009-08-10T14:52:57 mrpeters-isl: i'd recommend leaving in the \set, the BEGIN; (important!), and the SET TRANSACTION ISOLATION LEVEL... 2009-08-10T14:53:22 ok, keeping 2009-08-10T14:53:49 mrpeters-isl: but then you're back in the situation of "most of the upgrade script works within a BEGIN/COMMIT transaction, and some things get rolled back when it runs into the error, but some things don't, because they aren't something you can roll back with a transaction" 2009-08-10T14:54:14 hmm, so please dont tell me i should restore the db again haha 2009-08-10T14:54:34 but i suspect thats where we are 2009-08-10T14:55:29 ill just do that, to be safe 2009-08-10T14:55:36 better than getting screwed again after more work 2009-08-10T14:56:08 that is "safest", but you could probably also come up with a "INSERT and UPDATE get rolled back, DROP and ALTER don't" rule of thumb and comment out the lines that succeeded and were not rolled back. 2009-08-10T14:57:08 if you do that and then run into other errors, you can make a good list of things to correct, then do a last restore, run corrections, run upgrade script. 2009-08-10T14:57:55 yep, thats my thought process now too 2009-08-10T14:57:58 thanks for the help my friend 2009-08-10T14:58:59 'welcome! 2009-08-10T15:05:31 *** agJohn has joined #openils-evergreen 2009-08-10T15:11:27 jeff: wait, what? anything inside a transaction will get rolled back, including DROP and ALTER (and TRUNCATE, and any other DDL) 2009-08-10T15:12:19 (sorry, reading "INSERT and UPDATE get rolled back, DROP and ALTER don't" in isolation, I apologize I'm out of context there) 2009-08-10T15:12:36 OK. I'm confused. The guts of the check constraint on 1.4.0.4's config.rule_circ_duation.name column is: 2009-08-10T15:12:38 CHECK (name ~ '^\\w+$'::text); 2009-08-10T15:12:39 miker_: i was not certain, it was an example. 2009-08-10T15:12:40 So, that looks to me like beginning of string, then any alphanumeric or _, followed by any number of other alphanumerics or _ , and the end of the string--right? 2009-08-10T15:12:41 So what's its problem with 'default' (which it rejects)? 2009-08-10T15:12:43 Is there some setting that's not enabled or something on the system? Replacing the ~ operator with SIMILAR TO doesn't quite work, but if I drop the ^ and $, it does.... 2009-08-10T15:12:45 Postgres version is 8.2.13; it's happily hosted earlier versions of EV DB's. 2009-08-10T15:13:06 sorry--it started underlining when I meant to just have an _ 2009-08-10T15:13:07 *** mrpeters-isl has quit IRC 2009-08-10T15:13:21 miker_: and i didn't look it up to confirm. not sure where in the process i thought we had an indicator of "something in between BEGIN and COMMIT in the upgrade script was rolled back while something else was not" 2009-08-10T15:13:56 miker_: i knew enough to know that i needed to check docs on what can/can't be rolled back, but didn't make time to do so. 2009-08-10T15:14:42 jeff: :) ... again, it just caught my eye and I wanted to through that out there ... sorry for "yelling" :) 2009-08-10T15:14:43 miker_: any tips on failures during the upgrade scripts? is there a good way of running-until-clean? 2009-08-10T15:15:27 depends on the failure mode ... the duplicate locations above, that should be addressed pre upgrade (no good way to do it automatically) 2009-08-10T15:16:33 miker_: sure, but say mrpeters runs the upgrade script, gets that error, fixes the error on the db instance that he just tried to upgrade... can he expect to be able to run the upgrade script again to retry? 2009-08-10T15:16:43 you yes 2009-08-10T15:16:44 er 2009-08-10T15:16:52 s/you/oh 2009-08-10T15:17:20 as long as \set ON_ERROR_STOP 1 is there :) 2009-08-10T15:17:40 if not, it'll need fixination 2009-08-10T15:18:16 okay. i think the problem arose when the script was run with the BEGIN; line removed. that probably explains where I started to question why some things appeared rolled back and others didn't. 2009-08-10T15:18:25 miker_: thanks, as always :) 2009-08-10T15:29:55 RE the check constraint problems above; it appears that DROP CONSTRAINT is quite effective :~\ 2009-08-10T15:30:34 *** Alpha-GJohn has left #openils-evergreen 2009-08-10T15:32:04 agJohn: interesting. fwiw, i read your interpretation of the constraint the same. 2009-08-10T15:32:20 agJohn: when is it having trouble with the constraint and "default"? 2009-08-10T15:32:35 agJohn: is this during upgrade? 2009-08-10T15:34:19 Nope, not an upgrade. Here's the INSERT that fails on the check constraint in question: 2009-08-10T15:34:20 Oh, crap--I know what it is. This POJ SQL tool that in most respects is a fine piece of software, may be messing things up with the " " goop it adds: 2009-08-10T15:34:22 INSERT INTO "config"."rule_circ_duration"("id", "name", "extended", "normal", "shrt", "max_renewals") 2009-08-10T15:34:23 VALUES (1, 'default', '21 days', '21 days', '21 days', 3) 2009-08-10T15:35:55 Yup, that's it. Somehow those double-quotes mess it up. Sheesh. 2009-08-10T15:36:24 Oh, wait, I guess I have to put the constraint back before doing the testing, do you think? (!) 2009-08-10T15:36:34 * jeff grins 2009-08-10T15:37:08 agJohn: i'd be interested to see the sql statement and postgresql error when you try (after returning the constraint) 2009-08-10T15:37:36 agJohn: also, be sure your constraint goes back in the same way... i know there were some escapes in the one you pasted :) 2009-08-10T15:38:28 miker_: just wondering, but any logic to why some statements in the upgrade script 1.2.3-1.4-upgrade-db.sql are outside the transaction block? 2009-08-10T15:38:43 miker_: (rel_1_4_0_4 copy of that script, if it differs) 2009-08-10T15:40:02 Constraint: 2009-08-10T15:40:03 ALTER TABLE config.rule_recuring_fine 2009-08-10T15:40:05 ADD CONSTRAINT rule_recuring_fine_name_check CHECK (name ~ '^\\w+$'::text); 2009-08-10T15:40:06 Failing insert: 2009-08-10T15:40:08 INSERT INTO config.rule_circ_duration(id, name, extended, normal, shrt, max_renewals) 2009-08-10T15:40:09 VALUES (1, 'default', '21 days', '21 days', '21 days', 3) 2009-08-10T15:40:11 Error message: 2009-08-10T15:40:12 ERROR: new row for relation "rule_circ_duration" violates check constraint "rule_circ_duration_name_check"; 2009-08-10T15:40:38 *** jenny has quit IRC 2009-08-10T15:43:02 agJohn: note that the constraint you added is rule_recuring_fine_name_check while the constraint in the error is rule_circ_duration_name_check 2009-08-10T15:43:49 dealing with two different tables config.rule_circ_duration and config.rule_recuring_fine 2009-08-10T15:44:07 agJohn: step back and see if sorting out that bit helps. :) 2009-08-10T15:46:02 *** meliss has quit IRC 2009-08-10T15:46:23 Sorry, just copied the wrong constraint from the file where I put them so I could drop them easily.... Here's the constraint as per pgAdmin III: 2009-08-10T15:46:25 ALTER TABLE config.rule_circ_duration 2009-08-10T15:46:26 ADD CONSTRAINT rule_circ_duration_name_check CHECK (name ~ '^\\w+$'::text); 2009-08-10T15:46:28 Note that the error is associated with the column in question from the insert.... 2009-08-10T15:47:10 * jeff nods 2009-08-10T15:50:08 It would appear that the purpose of the constraint is to avoid white-space in the name: "word" characters only. For whatever reason, it's being overly picky. I thought it might be the SQL tool, but I get the same results using pgAdmin III; did not, actually, try psql, but pgAdmin III is using native wire-protocol rather than ODBC, so that seemed to rule out any ODBC-related issue. Very... 2009-08-10T15:50:10 ...strange. Well, for now, I'll just drop the constraint. Any insight on this, miker_? 2009-08-10T15:50:54 agJohn: have you verified the constraint in psql and attempted the insert in psql? i wonder if the constraint being shown to you is not the current reality... 2009-08-10T15:51:16 agJohn: did you say what version of postgresql this is? 2009-08-10T15:53:20 from psql, "\d config.rule_circ_duration" will show the table definition 2009-08-10T15:53:28 (including constraints) 2009-08-10T15:55:02 *** kbeswick has quit IRC 2009-08-10T15:55:20 Pg version is 8.2.13 2009-08-10T15:55:22 I'll check psql, but I've never seen pg Admin III give wrong info. 2009-08-10T15:56:16 'course, at the moment, the constraint isn't there.... 2009-08-10T16:03:40 The constraint is declared in-line with the column definition in the CREATE TABLE: 2009-08-10T16:03:42 CREATE TABLE config.rule_circ_duration ( 2009-08-10T16:03:43 id SERIAL PRIMARY KEY, 2009-08-10T16:03:45 name TEXT NOT NULL UNIQUE CHECK ( name ~ E'^\\w+$' ), 2009-08-10T16:03:46 ... 2009-08-10T16:03:47 Not sure what the E does.... But it does not affect this particular issue, seemingly. I'll chase the constraint issue down later; gotta move on to getting something done for now. 2009-08-10T16:12:55 *** ben-ct has quit IRC 2009-08-10T16:14:08 *** jenny has joined #OpenILS-Evergreen 2009-08-10T16:14:45 jeff: Just BTW, here's the corresponding constraint on the config.rule_max_fine table as per psql: 2009-08-10T16:14:47 Check constraints: 2009-08-10T16:14:48 "rule_max_fine_name_check" CHECK (name ~ '^\\w+$'::text) 2009-08-10T16:14:50 It looks exactly the same in pg Admin. And, the declaration of it in the scripts looks just the same too. 2009-08-10T16:14:51 And, it also objects to the string literal 'default' as the value for the name column. 2009-08-10T16:14:53 So, I think we can rule out the SQL client. It's doing the same thing everywhere. 2009-08-10T16:15:58 Clarification: And, the declaration of it in the scripts looks just the same too -- that is, it's declared in-line and has the capital-E there in front of the reg. exp. 2009-08-10T16:19:46 agJohn: The E is explained at http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS " 2009-08-10T16:19:49 agJohn: The E is explained at http://www.postgresql.org/docs/current/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS "15:34 < agJohn> Nope, not an upgrade. Here's the INSERT that fails on the check constraint in question: 2009-08-10T16:19:53 " 2009-08-10T16:19:55 oof 2009-08-10T16:19:57 "15:34 < agJohn> Nope, not an upgrade. Here's the INSERT that fails on the check constraint in question: 2009-08-10T16:20:05 An escape string constant is specified by writing the letter E (upper or lower case) just before the opening single quote, e.g., E'foo'. 2009-08-10T16:20:09 theeeeeeeeere we go 2009-08-10T16:20:42 sylvar: Interesting that it apparently looks/works the same w/ or w/o it. 2009-08-10T16:22:16 By looks, I mean that the info about the check constraint comes back from the DB (either via \d in psql or the Constraints node on the table in pg Admin) w/o the E--and it functions the same, odd way w/ or w/o it: rejects apparently good values. Odd. 2009-08-10T16:28:38 *** nodocs has joined #openils-evergreen 2009-08-10T16:30:54 It does look like there are several settings that your link mentions that might be involved. Although I did try it w/o the doubled backslash. Hmmm. 2009-08-10T16:30:56 Both the config params standard_conforming_strings & backslash_quote are commented out in postgresql.conf, so it's not immediately apparent what their values are (whatever the 8.2.13 defaults are). So, maybe this is why it's behaving oddly. Thanks! 2009-08-10T16:43:55 jeff: sorry, meetings all day ... there are some things in the upgrade script that may or may not have already happened, or that are fine to fail 2009-08-10T16:44:09 and now ... I'm running away :) 2009-08-10T17:25:59 *** jenny has quit IRC 2009-08-10T17:46:04 *** ben-ct has joined #OpenILS-Evergreen 2009-08-10T17:49:03 *** gmcharlt has quit IRC 2009-08-10T18:07:01 *** gmcharlt has joined #OpenILS-Evergreen 2009-08-10T18:21:33 *** kgs has quit IRC 2009-08-10T18:29:28 *** rschiffman_ has quit IRC 2009-08-10T19:08:07 *** csharp_GPLS has quit IRC 2009-08-10T19:23:03 *** ben-ct has quit IRC 2009-08-10T20:15:03 *** mck9 has quit IRC 2009-08-10T21:11:07 *** rsinger has quit IRC 2009-08-10T21:16:41 *** rsinger has joined #OpenILS-Evergreen 2009-08-10T21:38:49 *** brendan_ga has quit IRC 2009-08-10T22:22:56 *** brendan_ga has joined #OpenILS-Evergreen 2009-08-10T23:12:43 *** phasefx has joined #openils-evergreen 2009-08-10T23:46:34 *** brendan_ga has quit IRC