| # | Time | Nick | Message |
|---|
| # | 00:54:51 | phasefx__ has quit IRC |
| # | 01:01:32 | phasefx3_ has quit IRC |
| # | 01:19:54 | pmp_nfafk is now known as pmplett |
| # | 01:42:15 | atheos has quit IRC |
| # | 01:42:15 | StephenGWills has quit IRC |
| # | 01:42:15 | senator has quit IRC |
| # | 01:42:15 | moodaepo has quit IRC |
| # | 01:42:15 | lisppaste3 has quit IRC |
| # | 02:03:05 | artunit has quit IRC |
| # | 03:20:55 | artunit has joined #evergreen |
| # | 03:20:55 | atheos has joined #evergreen |
| # | 03:20:55 | StephenGWills has joined #evergreen |
| # | 03:20:55 | lisppaste3 has joined #evergreen |
| # | 03:20:55 | moodaepo has joined #evergreen |
| # | 03:20:55 | senator has joined #evergreen |
| # | 03:21:28 | lcassell has quit IRC |
| # | 03:21:30 | lcassell_ has joined #evergreen |
| # | 05:11:50 | StephenGWills has quit IRC |
| # | 05:11:50 | moodaepo has quit IRC |
| # | 05:11:50 | atheos has quit IRC |
| # | 05:11:50 | senator has quit IRC |
| # | 05:11:50 | lisppaste3 has quit IRC |
| # | 05:11:50 | artunit has quit IRC |
| # | 05:13:25 | artunit has joined #evergreen |
| # | 05:13:25 | atheos has joined #evergreen |
| # | 05:13:25 | StephenGWills has joined #evergreen |
| # | 05:13:25 | lisppaste3 has joined #evergreen |
| # | 05:13:25 | moodaepo has joined #evergreen |
| # | 05:13:25 | senator has joined #evergreen |
| # | 07:20:16 | wlayton has joined #evergreen |
| # | 07:28:14 | alxp has joined #evergreen |
| # | 08:30:12 | mck9 has joined #evergreen |
| # | 09:16:05 | wlayton has quit IRC |
| # | 09:16:05 | StephenGWills has quit IRC |
| # | 09:16:05 | moodaepo has quit IRC |
| # | 09:16:05 | atheos has quit IRC |
| # | 09:16:05 | senator has quit IRC |
| # | 09:16:05 | lisppaste3 has quit IRC |
| # | 09:16:05 | artunit has quit IRC |
| # | 09:20:56 | wlayton has joined #evergreen |
| # | 09:20:58 | senator has joined #Evergreen |
| # | 09:21:03 | artunit has joined #evergreen |
| # | 09:21:05 | moodaepo has joined #evergreen |
| # | 09:43:45 | dbs has joined #evergreen |
| # | 09:44:01 | matt__ has joined #evergreen |
| # | 09:44:53 | dbs | Musing out loud: to prevent multiple concurrent checkouts of a given target_copy from occurring (a bandaid solution while we figure out how those concurrent checkouts were triggered via renew in the first place) |
| # | 09:46:25 | dbs | ... add a unique constraint like action.circulation(target_copy, (COALESCE(checkin_time, 'ONLY ONE CONCURRENT CHECK OUT')) |
| # | 10:06:51 | atheos has joined #Evergreen |
| # | 10:09:19 | sboyette has quit IRC |
| # | 10:11:29 | dbs | Or something that actually works: CREATE UNIQUE INDEX only_one_concurrent_checkout_per_copy ON action.circulation (target_copy) WHERE checkin_time IS NULL; |
| # | 10:11:46 | chrissharp123 | dbs: the multiple concurrent checkouts has been a consistent problem in PINES and is supposed to be corrected in 1.4.0.7 - FYIS |
| # | 10:11:50 | chrissharp123 | fyi, that is |
| # | 10:12:04 | dbs | chrissharp123: oh? that's _really_ good to know |
| # | 10:12:06 | chrissharp123 | only time will tell :-) |
| # | 10:12:29 | dbs | seems likely that the same fix will be in 1.6.0.0 then, given that we're still at 1.5.9.conifer :) |
| # | 10:12:31 | chrissharp123 | it doesn't happen a lot, so I'm glad you caught it |
| # | 10:12:51 | chrissharp123 | you might ensure that the fix was not "PINES-specific" |
| # | 10:12:56 | dbs | chrissharp123++ # thanks for letting me know |
| # | 10:13:02 | chrissharp123 | some of our fixes are considered "client files" |
| # | 10:13:09 | chrissharp123 | happy to help |
| # | 10:13:22 | dbs | yeah, that's why I really hope people use the open bug tracker |
| # | 10:14:11 | dbs | I haven't filed this as a bug because I haven't reproduced it on a clean, stable release, but I will - oh I will :) |
| # | 10:15:13 | wlayton | dbs: The po files for trunk are available on the launchpad site. But for 1.6, should I be editing the po files under branch/rel_1_6_0 ? |
| # | 10:16:20 | dbs | wlayton: it's a bit of an evil problem |
| # | 10:17:02 | dbs | wlayton: if you edit trunk, then I'll roll those files into 1.6.0.1 |
| # | 10:18:14 | dbs | I suppose we could push rel_1_6_0 and rel_1_6 and rel_1_4_0 and rel_1_4 branches into launchpad and create separate translation branches for those, but that gets complicated really fast. |
| # | 10:19:03 | wlayton | dbs: I take it that the "ideal" solution is for strings in "trunk" to get translated as they get added, and then when a branch is created, the new strings are already available... |
| # | 10:19:08 | dbs | have I mentioned that I don't really like having so many development branches open at once? |
| # | 10:20:29 | dbs | wlayton: I'm honestly not sure. |
| # | 10:20:55 | dbs | that would work as long as we never delete strings in trunk, or change their context |
| # | 10:21:42 | wlayton | dbs: Well, is it easier to forward-port strings from a branch to trunk, or backport strings from trunk to branches? |
| # | 10:21:55 | wlayton | I'm just trying to avoid duplicating translation work, if possible... |
| # | 10:22:20 | wlayton | (laziness being one of the programming virtues) |
| # | 10:22:35 | wlayton | and, er, translaters, too, I guess |
| # | 10:23:17 | dbs | wlayton: probably easier to forward-port strings from a branch to trunk |
| # | 10:23:47 | dbs | but from rel_1_4_0 to rel_1_4 to rel_1_6_0 to rel_1_6... that's still not clear |
| # | 10:23:58 | dbs | maybe I'm over-thinking it |
| # | 10:26:04 | dbs | I guess one advantage of launchpad is that if you translate the strings in trunk, the suggestions for those strings should be available in any of the other releases if those are added to launchpad |
| # | 10:32:33 | kbeswick has quit IRC |
| # | 10:32:33 | cpeach has quit IRC |
| # | 10:32:33 | chrissharp123 has quit IRC |
| # | 10:32:33 | atz has quit IRC |
| # | 10:32:33 | jmeeuwen has quit IRC |
| # | 10:32:33 | senator has quit IRC |
| # | 10:32:33 | alxp has quit IRC |
| # | 10:32:33 | jeff has quit IRC |
| # | 10:32:33 | jamesrf-afk has quit IRC |
| # | 10:32:33 | greg-g has quit IRC |
| # | 10:32:33 | eby has quit IRC |
| # | 10:32:33 | twirlip has quit IRC |
| # | 10:32:33 | AbizzalsX has quit IRC |
| # | 10:32:33 | _dkyle_ has quit IRC |
| # | 10:32:33 | phasefx2 has quit IRC |
| # | 10:32:33 | jeff_ has quit IRC |
| # | 10:32:33 | atheos has quit IRC |
| # | 10:32:33 | moodaepo has quit IRC |
| # | 10:32:33 | wlayton has quit IRC |
| # | 10:32:33 | mck9 has quit IRC |
| # | 10:32:33 | lcassell_ has quit IRC |
| # | 10:32:33 | gmcharlt_ has quit IRC |
| # | 10:32:33 | mrpeters-isl has quit IRC |
| # | 10:32:33 | wjr has quit IRC |
| # | 10:33:20 | kbeswick has joined #evergreen |
| # | 10:33:20 | wjr has joined #evergreen |
| # | 10:33:20 | mrpeters-isl has joined #evergreen |
| # | 10:33:20 | gmcharlt_ has joined #evergreen |
| # | 10:33:20 | lcassell_ has joined #evergreen |
| # | 10:33:20 | mck9 has joined #evergreen |
| # | 10:33:20 | wlayton has joined #evergreen |
| # | 10:33:20 | moodaepo has joined #evergreen |
| # | 10:33:20 | atheos has joined #evergreen |
| # | 10:33:20 | phasefx2 has joined #evergreen |
| # | 10:33:20 | jeff_ has joined #evergreen |
| # | 10:33:20 | _dkyle_ has joined #evergreen |
| # | 10:33:25 | jeff has joined #evergreen |
| # | 10:33:29 | kbeswick has quit IRC |
| # | 10:33:43 | _dkyle_ has quit IRC |
| # | 10:33:43 | jeff_ has quit IRC |
| # | 10:33:43 | phasefx2 has quit IRC |
| # | 10:33:47 | jeff_ has joined #evergreen |
| # | 10:33:53 | senator has joined #evergreen |
| # | 10:33:53 | alxp has joined #evergreen |
| # | 10:33:53 | cpeach has joined #evergreen |
| # | 10:33:53 | atz has joined #evergreen |
| # | 10:33:53 | jmeeuwen has joined #evergreen |
| # | 10:33:53 | chrissharp123 has joined #evergreen |
| # | 10:34:29 | AbizzalsX has joined #Evergreen |
| # | 10:34:35 | jamesrf-afk has joined #evergreen |
| # | 10:34:40 | kbeswick has joined #evergreen |
| # | 10:34:41 | twirlip has joined #evergreen |
| # | 10:34:44 | _dkyle_1 has joined #evergreen |
| # | 10:34:52 | jeff_ is now known as Guest97300 |
| # | 10:37:44 | jeff has joined #evergreen |
| # | 10:42:59 | phasefx2 has joined #evergreen |
| # | 10:48:07 | sboyette has joined #evergreen |
| # | 11:16:17 | matt__ | I've compiled opensrf on an Ubuntu server (karmic), but I can't start it..I get: Global symbol "$prefix" requires explicit package name at /opensrf/bin/opensrf-perl.pl line 30. am I missing a dependency or something? |
| # | 11:21:33 | dbs | matt__: what version of opensrf? |
| # | 11:22:19 | matt__ | 1.2.0 |
| # | 11:22:34 | dbs | can you paste line 130? |
| # | 11:22:37 | dbs | err, line 30? |
| # | 11:23:11 | matt__ | my $opt_config = "${prefix}/etc/opensrf_core.xml"; |
| # | 11:40:42 | eby has joined #evergreen |
| # | 11:42:37 | sboyette | dbs: do you know offhand if launchpad supports a concept like Trac's "Components", where things can be filtered by what area of development they involve/effect/impact? |
| # | 11:43:22 | wlayton | matt__: I suspect that you ran "./configure" instead of "./configure --prefix=/openils --sysconfdir=/openils/conf" before compiling |
| # | 11:43:59 | wlayton | I was able to get the same line 30 as you by doing that, at least. |
| # | 11:44:26 | sboyette | i'm coralling my thoughts on testing/qa todos and plans, and i want them somewhere public, but i don't want them getting in the way of regular tickets |
| # | 11:44:36 | sboyette | i suppose i could start another instance |
| # | 11:44:37 | eby has quit IRC |
| # | 11:44:49 | eby has joined #evergreen |
| # | 11:45:46 | matt__ | wlayton: i did, does it depend on being under /openils? |
| # | 11:47:40 | wlayton | matt__: It shouldn't, but I've never tried it another way yet... |
| # | 11:49:22 | sboyette | clearly something depends on ./configure's 'prefix' argument being explicitly set |
| # | 11:49:31 | sboyette | sounds like a bug against the autotools stuff |
| # | 11:49:39 | sboyette | as a starting point, anyhow |
| # | 11:49:59 | wlayton | sboyette: And 'sysconfdir', too |
| # | 11:51:25 | sboyette | matt__: wanna do the honors? :) https://launchpad.net/evergreen |
| # | 11:51:33 | matt__ | i got 1.2.0 to run fine on a debian VM a couple weeks ago using /openils, but this is a VPS someone's set up here for my evergreen experimenting...i was going to put opensrf in /opensrf and evergreen in /openils or /evergreen or something so i can keep straight which components belong to which thing |
| # | 11:57:57 | lisppaste3 has joined #evergreen |
| # | 12:15:12 | jamesrf-afk is now known as jamesrf |
| # | 12:17:23 | dbs | sboyette: mostly away from keyboard for the next bit, but tagging is certainly supported |
| # | 12:18:11 | dbs | looks like that |
| # | 12:18:19 | dbs | (tagging) would be the way to go |
| # | 12:23:03 | dbs has quit IRC |
| # | 12:31:42 | brendan_ga has joined #evergreen |
| # | 12:31:49 | sboyette | unsure that i like tagging as a solution. people can enter *anything* as a tag, and the only place they show up is in the tag cloud thinger on the right-hand side of the main bugs page. |
| # | 12:32:05 | sboyette | consistency is very good in a ticketing system. tagging is generally inconsistent |
| # | 12:41:00 | branflakes has joined #Evergreen |
| # | 12:51:26 | atz has quit IRC |
| # | 12:53:15 | branflakes | I just recently did a pg_dump, followed by a pg_restore of my Evergreen database, and some kinds of searches (specifically, ISBN searches) are taking much longer than they used to. |
| # | 13:04:55 | dbs has joined #evergreen |
| # | 13:05:46 | branflakes | I thought there might be database cruft, so I VACUUMED, then did a VACUUM FULL on metabib.full_rec, which VACUUM suggested, and then thought it might be an indexing thing so I did REINDEX TABLE metabib.full_rec. |
| # | 13:07:51 | dbs | sboyette: it's possible to create a set of official tags |
| # | 13:08:14 | dbs | sboyette: see also "blueprints" for to/dos / planning stuff |
| # | 13:08:39 | dbs | branflakes: are default_statistics set to 100? |
| # | 13:09:21 | dbs | by default, they would be 10; if you set them to 100 and run "ANALYZE" then the database planner has a much better idea of the distribution of data |
| # | 13:10:18 | dbs | sboyette: you might want to try reading https://help.launchpad.net/Bugs before you make up your mind |
| # | 13:12:03 | branflakes | dbs: I have a setting called 'default_statistics_target' that's commented out, but has a default value of 10. Is that the one you mean? |
| # | 13:12:18 | dbs | branflakes: ah, yeah, that would be it |
| # | 13:12:30 | dbs | (working from brain, which is usually defective) |
| # | 13:13:50 | twirlip has left #evergreen |
| # | 13:15:06 | branflakes | dbs: It's just the brain's job to get you close enough to the target for intuition to figure the rest out. dbs++ |
| # | 13:15:21 | dbs | sboyette: see also https://dev.launchpad.net/LaunchpadBugTags for an example of official tags, with links to queries for bugs with specific tags |
| # | 13:15:41 | dbs | branflakes: increment me if your problem is actually solved :) |
| # | 13:16:12 | dbs | branflakes: any plans for a BC-area mini-conference or the like in the spring? |
| # | 13:17:04 | branflakes | Well, dbs-- for now, then. |
| # | 13:17:23 | dbs would like an excuse to travel west |
| # | 13:23:39 | branflakes | The BC Library Association conference is happening the same week as Grand Rapids, otherwise we'd have up with a reason to get you out here |
| # | 13:23:53 | branflakes | Maybe we can bring you out to teach your developer's workshop. |
| # | 13:24:56 | dbs | ugh. BCLA conflicts with EGCon, OLA conflicts with code4libcon... damn provinces |
| # | 13:27:42 | eby has quit IRC |
| # | 13:27:59 | dbs | branflakes: if you opt for egcon, we'll have to coordinate our ghetto hotel stays |
| # | 13:28:39 | branflakes | haha: government has cut back on travel, but I'm going to try and make it anyway |
| # | 13:34:56 | jamesrf | i would love to have a pnw eg hackfest or unconference |
| # | 13:46:59 | sboyette | tweaked the bot doc from a bit, btw. added a chunk on the message-passing stuff, and some general cleanups. |
| # | 14:10:04 | brendan_ga has quit IRC |
| # | 14:12:47 | mck9 has quit IRC |
| # | 14:26:24 | brendan_ga has joined #evergreen |
| # | 15:05:53 | alxp has quit IRC |
| # | 15:15:15 | branflakes | dbs: setting default_statistics_target, reloading and doing an analyze of the full database didn't change the performance at all. |
| # | 15:15:59 | dbs | branflakes: see? no increment deserved |
| # | 15:17:05 | dbs | branflakes: is that on just the initial query for a given index, or if you do 10 queries in a row on the same index (say, the author index), do things get faster as the filesystem caches the indexes? |
| # | 15:20:16 | alxp has joined #evergreen |
| # | 15:20:28 | matt__ | so, i rebuilt osrf and installed under /openils, now it gives me a new error when trying to load |
| # | 15:20:37 | matt__ | Can't call method "documentElement" on an undefined value at /usr/local/share/perl/5.10.0/OpenSRF/Utils/SettingsParser.pm line 39. |
| # | 15:21:11 | sboyette | dbs: i'm all for a separate OpenSRF instance in launchpad. it needs more standalone, and that's where most of my initial plans are targeted anyhow :) |
| # | 15:21:54 | matt__ | i did run the dependency script with ubuntu-intrepid, being the closest to karmic, not sure if that might cause problems? |
| # | 15:23:32 | natschil has joined #evergreen |
| # | 15:24:25 | dbs | sboyette: cool, I'll set one up then |
| # | 15:25:00 | dbs | matt__: ah, OpenSRF 1.2.0 won't work with karmic |
| # | 15:25:52 | matt__ | dbs: will any version of osrf? |
| # | 15:25:56 | dbs | you'll need to check out either OpenSRF trunk or OpenSRF rel_1_2 branch, or apply some patches manually to 1.2.0, to make it work, as we haven't packaged up a release of OpenSRF in 4 months |
| # | 15:26:02 | matt__ | ah |
| # | 15:26:08 | dbs | sorry :( |
| # | 15:27:08 | matt__ | np, i don't mind checking it out from svn(?)...i thought the 1.2.0 tarball was more recent |
| # | 15:27:24 | natschil | dbs: is ejabberd from the karmic repos fine for opensrf? |
| # | 15:27:46 | branflakes | dbs: It fails the eyeball test - that is, both the initial query and a subsequent query seconds after the first completes are both slow. I am doing two runs under 'time' to determine whether the timing is actually different much. |
| # | 15:27:50 | dbs | natschil: it's fine, for opensrf trunk or rel_1_2 |
| # | 15:27:56 | matt__ | i'm going to go complain to my sys admin for not using debian ;) |
| # | 15:28:11 | wlayton | Has anyone seen a message from me on -dev in the past hour or so? It isn't appearing the in archives and I'm wondering if it got filtered. |
| # | 15:28:49 | dbs | wlayton: I have seen nothing from you |
| # | 15:28:56 | sboyette | wlayton: nope |
| # | 15:29:10 | branflakes | matt__: when installing from svn (definitely trunk, and possibly rel_1_2), you need to run autogen.sh in the root of the project to generate the autoconf files. |
| # | 15:29:11 | wlayton | Thanks. I'll re-send. |
| # | 15:29:50 | dbs | matt__: yeah, in addition to what branflakes said, the bottom of the README in the root dir has some developer instructions |
| # | 15:29:57 | branflakes | That got me caught up the first time, because Evergreen already has an autogen.sh that does something very different :) |
| # | 15:30:34 | branflakes | dbs: the second run was actually slightly slower. |
| # | 15:30:39 | branflakes | [by about a second] |
| # | 15:30:44 | matt__ | branflakes: yep, thanks :) come to think of it, i might have installed the trunk on the debian VM i was playing with |
| # | 15:30:55 | sboyette | speaking of opensrf releases, i got instructions from miker_ late wednesday on how to roll opensrf/openils tarballs. i'm working on it now. |
| # | 15:31:06 | natschil | btw, does anyone know what could be slowing down evergreen (1.6)? After installing it, it was really fast, but now it seems to have slowed down after cataloging books for several months....my prime suspect at the moment is large log files, but as I haven't been at the server for a while I can't check...any other thoughts as to what could be causing the problem so that I can go through them when I do check? |
| # | 15:31:11 | sboyette | (nightlies, not an official release) |
| # | 15:31:53 | natschil | sboyette: wouldn't it be easier to checkout svn and then just svn up and compile & install? |
| # | 15:32:16 | sboyette | natschil: i tend to agree, but i have my orders :) |
| # | 15:32:22 | dbs | branflakes: bizarre |
| # | 15:33:04 | dbs | branflakes: I assume the exact same query is lightning fast? |
| # | 15:33:40 | natschil | could not running autogen.sh for a while cause any issues? |
| # | 15:33:48 | alxp has quit IRC |
| # | 15:34:05 | sboyette | natschil: if the Makefile.am's have changed under you, yes |
| # | 15:34:19 | matt__ | wait wait, so eg has another autogen.sh file that doesn't build a configure script? what does it do? |
| # | 15:34:40 | natschil | sboyette: sorry, I mean /openils/bin/autogen.sh |
| # | 15:35:18 | natschil | matt__: I think it does various things...you need to run it if you update the fieldmapper or the org units. |
| # | 15:36:11 | dbs | all in favour of renaming /openils/bin/autogen.sh to /openils/bin/update_config.sh? and/or renaming root dir autogen.sh to bootstrap? :) |
| # | 15:36:16 | branflakes | matt__: Among other things it generates static content that is used in the OPAC for org unit selection, and can be used to calculate orgunit proximity for holds routing. |
| # | 15:36:34 | branflakes | dbs: those two runs were the exact same query. |
| # | 15:36:35 | natschil | update_config.sh++ #autogen.sh is too ambigous |
| # | 15:37:00 | dbs | branflakes: that's nutty. is memcached running? |
| # | 15:37:47 | branflakes | Yes, otherwise user sessions wouldn't work, right? |
| # | 15:38:06 | natschil has quit IRC |
| # | 15:41:17 | branflakes | I also see the same behaviour on one of the test databases we're using to test our migration to 1.6 and PG 8.3, so it's not just the result of (one) bad database dump or restore. |
| # | 15:41:59 | dbs | branflakes: hmm. well, if an identical query is returning slow, it sounds less like a postgresql problem and more like a problem elsewhere in the stack - because results for an identical query should just get pulled straight from memcached |
| # | 15:42:58 | dbs | of course, I'm not sure how you're running the queries. obviously a query via psql has no idea about memcached |
| # | 15:43:43 | dbs | sboyette: might be worthwhile dumping those build instructions into a wiki page |
| # | 15:45:20 | branflakes | No, sorry, those were direct queries through psql. |
| # | 15:46:39 | dbs | branflakes: hmm. did you paste the query that you're running? |
| # | 15:48:00 | lisppaste3 | branflakes pasted "Three Minute SQL" at http://paste.lisp.org/display/91173 |
| # | 15:49:43 | dbs | branflakes: are you coming from 1.2 to 1.6? one change is that metabib.full_rec became a view on metabib.real_full_rec |
| # | 15:50:02 | dbs | would be useful to see the EXPLAIN of that as well |
| # | 15:50:18 | dbs | e.g. EXPLAIN SELECT ... |
| # | 15:50:35 | branflakes | Yeah, sorry, I sent that stuff off to ESI last night, but they're closed or shortstaffed for Yankee Turkey Day. |
| # | 15:51:15 | dbs | shouldn't make a difference, but try f.value = instead of f.value LIKE (as you have no wildcards there) |
| # | 15:52:19 | lisppaste3 | branflakes annotated #91173 "Three Minute SQL, Explained" at http://paste.lisp.org/display/91173#1 |
| # | 15:53:08 | lisppaste3 | dbs annotated #91173 "EXPLAIN from Conifer's database (postgresql 8.3)" at http://paste.lisp.org/display/91173#2 |
| # | 15:53:08 | branflakes | dbs: The second explain is from one of our testing databases, made from an earlier pg_dump-and-restore of our production system. |
| # | 15:54:43 | branflakes | dbs: we're experiencing this problem in both our 1.2-to-1.6 migrated database, and our 1.2-to-1.2-dumped-and-restored database. |
| # | 15:54:48 | branflakes | All the examples are from 1.2. |
| # | 15:56:25 | dbs | the plan looks almost identical, with the exception of the full_rec vs. real_full_rec change |
| # | 15:58:01 | dbs | wow. if I change my query to point at real_full_rec instead of full_rec, the cost goes up insanely high |
| # | 16:01:30 | dbs | branflakes: I'd like to see the plan from your 1.6 migrated database |
| # | 16:03:19 | lisppaste3 | branflakes annotated #91173 "1.2-to-1.6-migration explains" at http://paste.lisp.org/display/91173#3 |
| # | 16:03:24 | dbs | also, do these databases have locale=C? |
| # | 16:03:33 | dbs | database clusters, rather |
| # | 16:03:38 | branflakes | I don't even know how to determine that |
| # | 16:07:03 | brendan_ga has quit IRC |
| # | 16:07:43 | dbs | try " show LC_CTYPE;" |
| # | 16:09:14 | branflakes | Now we're getting somewhere! |
| # | 16:10:21 | branflakes | The still-fast non production databases have LC_CTYPE 'C', but all the Ubuntu databases have LC_CTYPE 'en_CA.UTF-8'. |
| # | 16:13:20 | levani_el has joined #evergreen |
| # | 16:13:26 | levani_el | hello |
| # | 16:13:40 | levani_el | i have question about fixed field in marc editor |
| # | 16:14:03 | matt__ | woot, got osrf trunk working on karmic :D |
| # | 16:14:33 | levani_el | when i click right click on mouse i see empty list and when chenge any letters in fixed field nothing changing |
| # | 16:14:58 | levani_el | may i add letters in manually? |
| # | 16:16:09 | levani_el | and add letters in list? |
| # | 16:19:30 | dbs | branflakes: yes, that would make a big difference |
| # | 16:20:07 | dbs | you will need to add a text_pattern_ops index on metabib.full_rec.value if you're going to use a locale other than 'C' |
| # | 16:20:51 | dbs | that will enable your database to actually use an index, rather than scan every row in the database |
| # | 16:21:22 | dbs | CREATE INDEX metabib_full_rec_value_tpo_index ON metabib.real_full_rec (substring(value,1,1024) text_pattern_ops); |
| # | 16:21:33 | dbs | matt__++ |
| # | 16:21:58 | dbs | levani_el: sorry, I'm not very good with the fixed fields :( |
| # | 16:22:35 | levani_el | i use marc templates all works good...but need change something |
| # | 16:22:37 | dbs | branflakes: maybe we should add the results of SHOW LC_TYPE to settings-tester.pl |
| # | 16:22:40 | levani_el | who answer me? |
| # | 16:22:54 | dbs | fwiw - we use en_US.UTF8 in Conifer, but we're evil |
| # | 16:23:49 | dbs prepares his invoice for handling equinox's support :) |
| # | 16:23:56 | matt__ | hey, before i bugger off for the weekend, anyone have any good suggestions/resources for learning about perl? i have learning perl and perl cookbook at home, but they're both about 9 or 10 years old...not sure how relevant they are anymore |
| # | 16:25:04 | dbs | matt__: a lot of the basics are still relevant, although I have to admit to a fondness for Programming Perl 3rd edition |
| # | 16:25:48 | dbs | (which was published in 2000, geez) |
| # | 16:26:07 | matt__ | hah i think that's written by the same author as learning perl |
| # | 16:26:23 | matt__ | it's the thicker o'reilly perl book |
| # | 16:26:25 | dbs | randall schwartz? yeah |
| # | 16:26:48 | dbs | chromatic, who blogs at http://modernperlbooks.com/mt/index.html, has a book in progress that is (as the hostname promises) modern |
| # | 16:27:16 | dbs | you'll also find a lot of chromatic posts on perlmonks.org |
| # | 16:27:49 | dbs | http://github.com/chromatic/modern_perl_book |
| # | 16:28:51 | matt__ | awesome, added to delicious |
| # | 16:29:03 | matt__ | thanks, dan :) |
| # | 16:29:25 | branflakes | dbs: Maybe we should change the default install instructions to call createdb -E UNICODE --lc-ctype C evergreen_database instead of letting the fates choose for us. |
| # | 16:29:41 | levani_el | mister dan who give me answer about mark and staff client work? |
| # | 16:32:22 | dbs | branflakes: it's actually at the initdb level |
| # | 16:32:54 | dbs | initdb --locale=C |
| # | 16:33:05 | dbs | from whence you create your databases |
| # | 16:33:39 | branflakes | Is that possibly a debian-ism. |
| # | 16:33:41 | branflakes | ? |
| # | 16:33:59 | branflakes | I've never called initdb anywhere that I know of |
| # | 16:36:06 | dbs | branflakes: yep, debian / ubuntu invoke it automatically when you install postgresql |
| # | 16:36:12 | matt__ has quit IRC |
| # | 16:36:21 | dbs | now, with postgresql 8.4 you can set --lc-type as part of createdb |
| # | 16:36:24 | branflakes | Yeah, I see what you mean now. |
| # | 16:36:40 | dbs | levani_el: sorry, if nobody is answering you here, perhaps you'll have more luck on the mailing list |
| # | 16:37:01 | dbs | levani_el: many of the people that would normally be here are on vacation (it's a holidy in the United States) |
| # | 16:37:19 | levani_el | thank mister dan |
| # | 16:37:47 | branflakes | dbs: i was reading the 8.4 docs instead of 8.3, that's where the confusion came from. |
| # | 16:38:50 | dbs | branflakes: we should make it more visible in the documentation, but as of 1.4 or 1.6 I added the text_pattern_ops indexes that should (largely) restore the performance hits |
| # | 16:41:26 | branflakes | dbs: did you add them very recently? As in: are they only in svn, or a packaged release? |
| # | 16:41:39 | dbs | branflakes: should be in 1.4, lemme look |
| # | 16:41:42 | branflakes | Because I am experiencing the same issues on a 1.6 database. |
| # | 16:42:23 | miker_ | dbs: ha ... also, fwiw, I have always advocated (lists, on the wiki at one time) using --locale=C, and I always do that myself, to avoid the issues branflakes is seeing now. it should also make multi-language colation easier (by removing one layer of complication/confusion) |
| # | 16:42:25 | dbs | they're in rel_1_4_0 |
| # | 16:42:34 | dbs | miker_: I know, I know |
| # | 16:42:38 | miker_ | (ha to the invoice, I mean) |
| # | 16:42:47 | dbs | :) |
| # | 16:43:16 | dbs | branflakes: can you run \d on metabib.real_full_rec on your 1.6 database? |
| # | 16:44:27 | branflakes | I take it back, it is about 4 times faster. |
| # | 16:44:27 | dbs | miker_: it's the tension in the docs between making evergreen as easy as possible to install and play with (single-server scenario) vs. optimized for performance for production |
| # | 16:44:50 | dbs | branflakes: heh, so only 45 seconds then? |
| # | 16:44:57 | branflakes | Yes. |
| # | 16:45:16 | dbs | would certainly be interesting to compare on the same hardware with the cluster init'ed to locale=C |
| # | 16:45:33 | dbs | cause I know you have all kinds of time :) |
| # | 16:45:34 | branflakes | Yeah, I'm going to try that as tonight's attempt at a fix. :) |
| # | 16:45:56 | miker_ | dbs: oh, I understand ... the problem is that we've (well, I've) been seeing lots of problems cause by non-unicode distro-initdb'd clusters |
| # | 16:46:40 | dbs | wow, non-unicode? that's really ugly. |
| # | 16:46:49 | miker_ | particularly on debian, where the default system encoding seems to be latin1 |
| # | 16:47:06 | dbs | huh, certainly wasn't for us (not on debian lenny, anyway) |
| # | 16:47:52 | brendan_ga has joined #evergreen |
| # | 16:48:11 | miker_ | the user logs in to a shell where it's configured for latin1, su's to root (no -, still latin1) and uses apt-get to install PG, which causes initdb to run, and by default there's no encoding specified ... so guess what's used for initdb? :( |
| # | 16:49:46 | miker_ | or, that's as close as I can get to a root-cause scenario... I get that about once a month |
| # | 16:50:03 | dbs | ah, silly people not using su - :) |
| # | 16:51:32 | dbs | sounds like it would be worth restoring the initdb command, and whatever else is necessary to make the right things happen on ubuntu and debian |
| # | 16:52:40 | levani_el has quit IRC |
| # | 17:32:03 | wlayton has quit IRC |
| # | 17:32:07 | pmplett is now known as pmp_hurly |
| # | 17:35:02 | jeffdavis has joined #evergreen |
| # | 18:05:30 | dbs has quit IRC |
| # | 19:36:06 | jamesrf is now known as jamesrf-afk |
| # | 20:59:43 | pmp_hurly is now known as pmplett |
| # | 21:00:54 | jeffdavis has left #evergreen |
| # | 21:33:10 | jamesrf-afk is now known as jamesrf |
| # | 22:26:57 | jamesrf_ has joined #evergreen |
| # | 22:27:21 | jamesrf_ is now known as james---- |
| # | 22:27:40 | jamesrf is now known as james-na |
| # | 22:27:44 | james---- is now known as jamesrf |
| # | 22:45:33 | jamesrf has left #evergreen |
April 10-13