Evergreen ILS Website

IRC log for #evergreen, 2014-10-31

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to the server's local time.

Time Nick Message
01:54 Stompro joined #evergreen
06:40 mtate joined #evergreen
06:40 eeevil joined #evergreen
06:41 TaraC joined #evergreen
06:41 phasefx joined #evergreen
06:41 Callender joined #evergreen
06:42 graced joined #evergreen
08:06 rjackson-isl joined #evergreen
08:15 ericar joined #evergreen
08:15 collum joined #evergreen
08:24 ericar left #evergreen
08:25 ericar joined #evergreen
08:29 akilsdonk joined #evergreen
08:30 mrpeters joined #evergreen
08:41 wsmoak joined #evergreen
08:44 kmlussier joined #evergreen
08:55 Shae joined #evergreen
09:00 mmorgan joined #evergreen
09:02 sarabee joined #evergreen
09:37 yboston joined #evergreen
09:47 wsmoak left #evergreen
09:53 kmlussier Happy Halloween!
09:59 berick Happy Friday!
10:00 ericar_ joined #evergreen
10:12 rjackson-isl There are going to be some rather cold kids for Halloween in Indiana this year! (rain/snow and 30-40 MPH wind gusts predicted!)
10:13 kmlussier We're supposed to be seeing that weather tomorrow.
10:13 rjackson-isl yuk :-(
10:21 Dyrcona joined #evergreen
10:29 csharp @isithalloween?
10:29 pinesol_green csharp: Yeah, well, you know, that's just like uh, your opinion, man.
10:30 berick heh
10:30 berick pinesol_green doesn't recognize pagan holidays
10:30 pinesol_green berick: It reads like a Nigerian 419 scam, but I think it is a sincere question sent to the wrong list.
10:30 pinesol_green berick: I am only a bot, please don't think I'm intelligent :)
10:32 kmlussier @eightball Is it halloween?
10:32 pinesol_green kmlussier: The answer is a resounding no.
10:33 collum @eightball is it All Saint's Eve
10:33 pinesol_green collum: It shall be.
10:33 berick hah
10:33 kmlussier heh
10:33 collum tee hee
10:34 Dyrcona It's Samhain.
10:34 Dyrcona ;)
10:35 * mmorgan is not looking forward to driving home through Salem, MA this evening :-(
10:36 jcamins mmorgan: will you be cursed?
10:37 mmorgan hopefully, no, but nearly 100,000 revelers are expected to descend on the city tonight.
10:38 tspindler joined #evergreen
10:38 jcamins According to Wikipedia, that's more than twice the population of the town.
10:39 collum That's 99,996 more people than came to my door for Trick-or-Treat last year.
10:41 jcamins I don't think we were home during our building's trick-or-treating last year.
10:42 collum Not many houses in our subdivision. Most of the kids go to a more populated neighborhood.
10:44 jcamins We have 204 units in our building. I'm not sure how many kids trick-or-treat.
10:44 * jcamins realizes suddenly that he lives in a building with more people than the town where his wife grew up.
10:46 kmlussier We get about as many trick or treaters as collum does. It may also be the first time in years I'm not going out trick or treating. The kids want to do it on their own. :(
10:48 ericar_ joined #evergreen
10:49 Dyrcona joined #evergreen
10:50 csharp @who will go as The Dude for Halloween?
10:50 pinesol_green artunit will go as The Dude for Halloween.
10:56 tspindler we were looking for areas to cut the size of our database (we are retaining audit records for only 6 months) but I was wondering if anyone retains records in the holds_transit_table and transit_copy table for a certain period of time
10:57 csharp tspindler: we haven't done any deletions like that, but I'd be interested in ways to reduce our DB size too
10:58 tspindler i'm looking at tables that are easy to remove rows at this point,  some time we might want to look at copies, bibs and patrons but I know there are a lot of hazards with touching those
10:59 csharp of course, the DB size in the filesystem won't shrink without a VACUUM FULL or a pg_dump/pg_restore
11:00 csharp we got rid of some older resolved billings/payments a couple of years ago - it was complicated :-/
11:01 bshum tspindler: We periodically go and delete swaths of auditor.* table data.
11:02 bshum And I try to avoid inserting more bre history every full reingest.
11:02 bshum Where it's just the same ol' thing
11:02 csharp yeah, we typically TRUNCATE auditor tables with each upgrade
11:03 bshum Additionally, Dyrcona helped to write for us a more complicated deletion script that goes and kills dead bibs, call numbers, etc.
11:03 bshum Call numbers especially can get hefty if you use the unified editor
11:03 bshum Since it always creates a new entry every time someone edits
11:03 csharp that would be nice - is that shared anywhere, bshum ?
11:03 bshum And also if you use URI's
11:03 bshum Since every time you load new MARC with URI, it deletes and creates anew fresh entries
11:04 bshum Which can add up very, very quickly
11:04 tspindler yes, i have seet some of the issues and i did ask Dyrcona about his script
11:04 tspindler bshum, csharp:  is it only the auditor table you touch regularly?
11:04 csharp yeah, pretty much
11:05 bshum "regularly" being once every year or so to remove the previous year, sure.
11:05 bshum Course we've managed to keep adding more RAM to our database hardware to keep just ahead of our full DB size in memory.
11:05 Dyrcona It only deletes bibs/call numbers if there are no copies or uris, and deleted ones count, so the call numbers must be dangling.
11:05 bshum And that helps too.
11:06 Dyrcona And, yeah, it actually deletes them from the database by removing a bunch of triggers/rules first.
11:06 tspindler i have a cron that removes anything older than 6 months in the auditor tables each night
11:07 tspindler i wonder sometimes if we should just keep 3 months
11:07 Dyrcona I think we keep less than 6 months in most auditors, maybe 30 days or so.
11:07 bshum Mostly just policy and troubleshooting.
11:07 bshum I think doing a vacuum full would lock the table, no?
11:08 collum Does anyone clean up old completed triggered events?
11:08 bshum Probably not really great.
11:08 tspindler gmcharlt once ran a cleanup on our edi messages but we have not done that regularly
11:08 bshum As csharp says, if you don't do a vacuum full, you don't actually get the disk space back.
11:09 bshum That's why we only delete from the tables during upgrade times when we plan to tidy up the whole DB at once anyways.
11:09 Dyrcona Yeah, but the disk space is still available for the table to use.
11:09 bshum collum: I usually leave those where they are.  Inevitably someone asks "why did X person not get a notice?" and we drag out the data to prove they did in fact get it generated.
11:10 bshum But I can see value in eventually nuking some of that.
11:10 Dyrcona bshum: The answer to that is usually, "It probably went to their junk folder."
11:10 bshum Dyrcona: Well that's always my first answer.
11:10 tspindler there are a lot of rows in the event tables for us also but we do use it for trouble shooting also,  however I think we only probably need a short retention period fro those
11:11 bshum Followed by "Are they using Yahoo? Then nevermind what common sense expects..."
11:11 Dyrcona Email is horribly broken, but then I think everything is.
11:11 csharp or "The email provider accepted our message without complaint, then marked it as spam internally before it got to the user"
11:13 Dyrcona Erm, well, that's kinda what I said. ;)
11:14 Dyrcona The best is when they accept it, then just silently discard it without delivering it.
11:14 Dyrcona We get all kinds of shit from people saying they didn't get an email, when the ISP said 220 OK.
11:15 Dyrcona Don't blame me. Blame your provider.
11:15 Dyrcona Yep, irredeemably broken....
11:15 collum Thanks bshum.  But after a certain period of time, you probably don't need the proof anymore.
11:15 csharp Dyrcona: exactly
11:18 Dyrcona Then there are the people who seem to use "Mark as spam" instead of "Delete."
11:18 * gmcharlt notes that the Pg wiki page on vacuum full is mostly concerned with recommending alternatives to vacuum full: https://wiki.postgresql.org/wiki/VACUUM_FULL
11:18 ericar_ joined #evergreen
11:20 tspindler one other area I forgot about is we purge report outputs after 2 months also
11:20 Dyrcona Heh. Looking at the script I wrote 7 months ago and I see this: "SET LOCAL synchronous_commit TO OFF;"
11:21 Dyrcona I think to myself, "Hmm. I musta had a good reason to do that, but what was it?"
11:21 ericar left #evergreen
11:33 mllewellyn joined #evergreen
11:36 sandbergja joined #evergreen
11:48 mrpeters joined #evergreen
11:49 sciani joined #evergreen
11:51 jeff comments++
12:10 akilsdonk joined #evergreen
12:43 bmills joined #evergreen
12:44 vlewis joined #evergreen
12:44 nhilton joined #evergreen
12:55 jeff marc_stream_importer.pl could probably benefit from a "watch directory" feature or wrapper.
12:56 jeff though i suppose that could also be done by having a script read marc records and feed them to stream_importer over tcp.
13:05 jeff and again i find myself wondering why it's not possible to delete individual records from a vandelay queue (or if i'm missing it) outside of at the API/db level.
13:07 hbrennan joined #evergreen
13:18 hbrennan joined #evergreen
13:32 nhilton joined #evergreen
13:47 jeff hrm. mostly-silent open-ils.pcrud.delete.vqbr failure to delete.
14:18 mrpeters1 joined #evergreen
14:31 gsams joined #evergreen
14:35 mmorgan Action trigger question: A trigger runs as scheduled, but event_output.is_error = TRUE because there was an error in the template. If the template is corrected and the trigger is run again, will another event be added since there was an error the first time?
14:35 mmorgan or do you get one shot whether there is an error or not?
14:35 mmorgan I know there's the event repeatability delay setting, but I'm not considering that.
14:41 mrpeters1 mmorgan: i think you have to set that is_error to NULL and set the state back to pending
14:41 mrpeters1 to have THAT exact event id run again
14:47 mmorgan mrpeters1: I have deleted from action_trigger.event in the past to get them to run again, but was wondering if it was necessary when there was an error.
14:48 mrpeters1 i think it is, if you want to "re-run" an event that was already detected
14:50 mmorgan luckily it doesn't happen too often, just often enough to forget how you did it in the past ;-)
14:52 jeff hrm. pcrud AppSession object returns an OK on open-ils.pcrud.transaction.begin but then undef on open-ils.pcrud.delete.vqbr
14:53 jeff oh hey, there's the error.
15:15 yboston I have a question about finishing a Postgres upgrade, from 9.1 to 9.2 on Debian Wheezy (7)
15:15 yboston It looks like I successfully was able to run "pg_upgradecluster 9.1 main" without any errors, but now…
15:15 yboston what do I need to do to finish the upgrade, if anything? Just restart opensrf in a "fresh" terminal window so that the latest aliases are in affect?
15:32 mrpeters1 left #evergreen
15:58 tspindler left #evergreen
16:14 wsmoak_ joined #evergreen
16:14 wsmoak_ joined #evergreen
17:08 mmorgan left #evergreen
17:17 pinesol_green Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
17:53 sarabee joined #evergreen
18:31 bmills joined #evergreen
18:36 bmills1 joined #evergreen
21:24 wsmoak_ joined #evergreen
21:24 wsmoak_ joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary