| 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 |
| 23:18 |
bshum |
Oy, more copy update issues |
| 23:18 |
bshum |
Edit -> Replace barcode doesn't work anymore in our systems :( |
| 23:18 |
bshum |
It goes through the process, but never actually updates the copies |
| 23:19 |
bshum |
Whatever this bug is that's sporadically affecting copy edits, it's starting to annoy me... |
