| Time |
Nick |
Message |
| 02:06 |
|
StomproJ joined #evergreen |
| 02:48 |
|
Stompro joined #evergreen |
| 03:29 |
|
StomproJ joined #evergreen |
| 04:02 |
|
Stompro joined #evergreen |
| 04:19 |
|
StomproJ joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:50 |
|
Stompro joined #evergreen |
| 06:07 |
|
StomproJ joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:45 |
|
StomproJosh joined #evergreen |
| 07:04 |
|
Stompro joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:28 |
|
agoben joined #evergreen |
| 07:28 |
|
Callender joined #evergreen |
| 07:56 |
|
eby joined #evergreen |
| 08:12 |
|
collum joined #evergreen |
| 09:03 |
|
jvwoolf joined #evergreen |
| 09:11 |
|
mmorgan joined #evergreen |
| 09:17 |
|
yboston joined #evergreen |
| 09:42 |
|
kmlussier joined #evergreen |
| 09:42 |
|
Dyrcona joined #evergreen |
| 09:48 |
Dyrcona |
phasefx: I was just perusing the slides from your 2014 conference presentation with Denish, and I have a question about the postgres settings. |
| 09:49 |
Dyrcona |
phasefx: Are they just what you recommend for testing? Some of them look like they would be good for regular use, too. |
| 09:54 |
phasefx |
Dyrcona: I don't remember what I presented on, but I imagine the Postgres part was Denish. I don't have any particular expertise with tuning Postgres :( |
| 09:54 |
Dyrcona |
OK. Thanks. |
| 09:55 |
Dyrcona |
To jog your memory, it was about Quality Assurance. |
| 09:55 |
phasefx |
ah, cool, thanks |
| 09:57 |
Dyrcona |
I'm tuning postgres for a development/testing server this morning, and I was looking for recommendations on the evergreen-ils.org site your presentation came up. |
| 10:02 |
kmlussier |
Dyrcona: Did you look at the report OmniTI did? I don't know if the recommendations there are the same as what was included in the presentation, but the report recommendations were definitely for production. https://wiki.evergreen-ils.org/doku.php?id=dev:testing:performance_report |
| 10:04 |
|
maryj joined #evergreen |
| 10:04 |
Dyrcona |
Apart from connection pooling and specific query changes, there's nothing much useful in that report. |
| 10:05 |
Dyrcona |
I'm doing the postgresql settings by hand, because no more pgtune. |
| 10:06 |
Dyrcona |
And, Denish, from OmniTI did the presentation with phasefx in 2014, so I guess those slides could be considered OmniTI's recommendations. |
| 10:07 |
Dyrcona |
However, from what I'm reading, I think the maintenance_work_mem, and possibly work_mem settings, are too low for production use, given the example 64GB in the presentation. |
| 10:07 |
Dyrcona |
pgtune would have set work_me to 64MB instead of 25MB, for example. |
| 10:08 |
Dyrcona |
For reference: http://evergreen-ils.org/wp-content/uploads/2014/04/eg14_QA-presentation-Jason-Denish.pdf |
| 10:21 |
|
rlefaive joined #evergreen |
| 10:39 |
kmlussier |
@coffee [someone] |
| 10:39 |
* pinesol_green |
brews and pours a cup of Espresso Nuevo, and sends it sliding down the bar to tsbere |
| 10:39 |
|
abowling joined #evergreen |
| 10:39 |
kmlussier |
@tea [someone] |
| 10:39 |
* pinesol_green |
brews and pours a pot of Dragon Pearl Jasmine, and sends it sliding down the bar to gmcharlt (http://ratetea.com/tea/harney/dragon-pearl-jasmine/1320/) |
| 10:51 |
dbs |
This sounds like a smoking gun for CDBI/action.pm missing checkin_workstation... 'Can't locate object method "checkin_workstation" via package "action::circulation"' |
| 10:51 |
* dbs |
checks commit logs |
| 11:02 |
dbs |
weird, nothing related to checkin_workstation seems to have changed in 2_10 since 2009 |
| 11:05 |
Dyrcona |
dbs: Is your IDL OK? |
| 11:07 |
jeff |
dbs: reminds me of an issue someone had earlier in the year, and it turned out to be you. not sure what the fix was: http://irc.evergreen-ils.org/evergreen/2016-09-16#i_267569 |
| 11:09 |
|
Christineb joined #evergreen |
| 11:11 |
dbs |
Dyrcona: my IDL is stock 2.10 |
| 11:11 |
dbs |
jeff: yeah, it certainly seems familiar |
| 11:12 |
dbs |
September was a crazy time. |
| 11:12 |
Dyrcona |
dbs: All right. Often, when I see that error, it's after I hosed the IDL. :) |
| 11:12 |
Dyrcona |
Well, the can't locate method whatever via package whatever message. |
| 11:13 |
dbs |
:) |
| 11:15 |
Dyrcona |
Question for the Pg gurus: |
| 11:15 |
|
brahmina joined #evergreen |
| 11:15 |
Dyrcona |
Most of the postgres tuning guides recommend setting shared_buffers to 25% of the system memory for a database-only server. |
| 11:16 |
Dyrcona |
However, when I look at configs from Evergreen-related postgresql.conf files, it is set much lower, like around 6.25%. |
| 11:16 |
Dyrcona |
Is there a reason based on the Evergreen work load? |
| 11:17 |
Dyrcona |
In one case it is even lower, and I'm thinking I might bump that one up to 6.25%. |
| 11:17 |
Dyrcona |
dbs: You made sure that the IDL contains the checkin_workstation member? I just checked the database and the column exists there, but didn't look in the IDL. |
| 11:18 |
Dyrcona |
The pg tuning docs recommend 5 to 15% for servers that do other things, just as a frame of reference. |
| 11:19 |
Dyrcona |
Granted, most of the pg tuning docs that I can find haven't been updated since Pg 8.4 was released. |
| 11:19 |
dbs |
Dyrcona: yep, the same as was added back in 2009 via 3d1d6323 |
| 11:19 |
pinesol_green |
dbs: [evergreen|scottmk] Add checkin_workstation column to action.circulation. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3d1d632> |
| 11:20 |
dbs |
It's like cstore has forgotten the definition or something. |
| 11:20 |
Dyrcona |
dbs: OK. I thought you had.... |
| 11:23 |
Dyrcona |
dbs: You found a bug, I think. |
| 11:24 |
Dyrcona |
dbs: workstation and checkin_workstation are not listed for action::circulation in CDBI/action.pm. |
| 11:25 |
Dyrcona |
Given that those are only the "essential" columns, I'm not sure that they need to be. |
| 11:26 |
Dyrcona |
If that were the problem, though, I guess everyone else would have seen it by now, too..... |
| 11:28 |
dbs |
Yeah, back then jeffdavis said they occasionally saw it too |
| 11:28 |
Dyrcona |
Well, I'd try adding the columns in CDBI/action.pm. It can't hurt. |
| 11:29 |
dbs |
As it's nullable, maybe it can hurt? :) |
| 11:29 |
Dyrcona |
Oh, right! |
| 11:29 |
Dyrcona |
That's why they're not listed. |
| 11:30 |
* Dyrcona |
forgot that detail. |
| 11:30 |
dbs |
yeah. if I can figure out the condition that's triggering it during holds processing, then maybe I can reproduce it and write a test and then fix it |
| 11:39 |
|
mdriscoll joined #evergreen |
| 11:40 |
dbs |
Dyrcona: I think the 25% ratio simply ends up being way too high for modern servers with tens of gigabytes of RAM and paradoxically can slow things down |
| 11:40 |
dbs |
The 25% rule of thumb was developed when servers had about as much RAM as phones do today |
| 11:41 |
Dyrcona |
dbs: Thanks. I can see that making sense. |
| 11:42 |
Dyrcona |
Yeah, the only time actual RAM numbers are mentioned in the docs, it's on the order of 512MB to 1GB. |
| 11:42 |
Dyrcona |
I guess the PostgreSQL wiki could use an update. :) |
| 11:43 |
dbs |
'tis the way of wikis :) |
| 11:44 |
Dyrcona |
:) |
| 11:45 |
dbs |
This old thread has some interesting discussion: https://www.postgresql.org/message-id/20140409114627.GA8686%40momjian.us |
| 11:48 |
Dyrcona |
dbs: Thanks, again. |
| 11:48 |
Dyrcona |
I missed that, uh, memo. :) |
| 11:49 |
csharp |
another thread of interest: http://libmail.georgialibraries.org/pipermail/open-ils-general/2016-February/012736.html |
| 11:49 |
dbs |
csharp++ |
| 11:51 |
Dyrcona |
I thought THP was only an issue with 2.6 kernels.... |
| 11:51 |
Dyrcona |
csharp++ dbs++ |
| 11:52 |
* Dyrcona |
is trying to figure out why he can't connect to the database via TCP... Isn't sure if it is a firewall issue or the pg_hba.conf isn't right. |
| 11:53 |
tsbere |
Dyrcona: My most recent bout of that was "ooops, wrong port" |
| 11:54 |
Dyrcona |
My version of that is postgres isn't running. :( |
| 11:54 |
tsbere |
Huh. Could still be pg_hba.conf isn't right, just to a more serious degree. ;) |
| 11:54 |
Dyrcona |
Could be, but more likely to be postgresql.conf. |
| 11:56 |
dbs |
listen_addresses or whatever |
| 11:58 |
Dyrcona |
checkpoint_segments is no longer an option in Pg 9.5. |
| 11:59 |
Dyrcona |
And, it's running. |
| 12:01 |
Dyrcona |
And, it's accepting tcp connections from localhost. |
| 12:01 |
Dyrcona |
And from a Linux VM on the same class B that I configured in pg_hba.conf. |
| 12:02 |
* Dyrcona |
just now realized that using 9.5 might cause a little problem with restoring from production dumps. |
| 12:10 |
dbs |
jeez, that's a funny-looking integer for aur.lineitem: http://pastebin.ca/3746689 |
| 12:11 |
* tsbere |
wonders who was doing what to trigger that |
| 12:12 |
Dyrcona |
Looks like CGI query parameters were doubled up. |
| 12:39 |
dbs |
The context was an attempt to adjust rates on an invoice apparently |
| 12:44 |
|
jeff_ joined #evergreen |
| 12:47 |
|
abowling joined #evergreen |
| 12:49 |
dbs |
just noticed we have lots of null 901 $b fields as our TCN source is typically null |
| 12:49 |
dbs |
and maintain_901 sets "b" => $_TD->{new}{tcn_source} unconditionally |
| 12:57 |
|
Guest74000 joined #evergreen |
| 13:06 |
Dyrcona |
dbs: Should be easy enough to fix. |
| 13:20 |
|
jvwoolf joined #evergreen |
| 13:28 |
|
rlefaive joined #evergreen |
| 14:07 |
|
gsams joined #evergreen |
| 14:52 |
|
collum_ joined #evergreen |
| 15:02 |
|
_bott_ joined #evergreen |
| 15:08 |
* dbs |
peers at actor.org_unit_closed with a close_end of 2017-02-20 23:59:59.589-05 and sees it as "2017-02-21 at 23:59" in the Closed Dates Editor |
| 15:08 |
dbs |
hrm |
| 15:08 |
kmlussier |
dbs: There's a bug for that |
| 15:09 |
kmlussier |
bug 1594937 |
| 15:09 |
pinesol_green |
Launchpad bug 1594937 in Evergreen 2.10 "Closed Dates Editor Displaying Incorrect Closed Duration" [Undecided,Confirmed] https://launchpad.net/bugs/1594937 |
| 15:10 |
dbs |
kmlussier++ |
| 15:13 |
dbs |
Would be nice to pull in bug 1432753 as well |
| 15:13 |
pinesol_green |
Launchpad bug 1432753 in Evergreen "Closed Dates Editor does not display the "All Day" verbiage" [Undecided,Confirmed] https://launchpad.net/bugs/1432753 |
| 15:18 |
Dyrcona |
dbs: In the meantime, you can revert ede7e78925a07dc800bc4e1dda10b2321d176f7d. |
| 15:18 |
pinesol_green |
Dyrcona: [evergreen|Bill Erickson] webstaff: browser client: Remove closed dates editor XUL-y requirements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ede7e78> |
| 15:19 |
|
collum joined #evergreen |
| 15:34 |
kmlussier |
@dessert |
| 15:34 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes for kmlussier |
| 15:36 |
dbs |
Dyrcona: yep, I was just working through the code and added a comment to each bug; I think we lost locale-sensitive date/time formatting with that commit as well |
| 15:41 |
berick |
ugh |
| 15:43 |
dbs |
the simple all-day fix is in bug 1432753 |
| 15:43 |
pinesol_green |
Launchpad bug 1432753 in Evergreen "Closed Dates Editor does not display the "All Day" verbiage" [Undecided,Confirmed] https://launchpad.net/bugs/1432753 |
| 15:43 |
dbs |
I'm not going to try touching the locale stuff though :) |
| 15:52 |
|
jason_ joined #evergreen |
| 15:53 |
jason_ |
Hi, dumb question. I'm setting up a test evergreen install on Ubuntu 16.04 (xenial) and I'm stuck on the opensrf installation |
| 15:53 |
bshum |
jason_: Well, if you're using OpenSRF 2.4.1, there isn't a makefile target for xenial |
| 15:54 |
bshum |
So that would fumble the start of the process with the initial prerequisite installation |
| 15:54 |
bshum |
But, what's your question? |
| 15:54 |
bshum |
:) |
| 15:54 |
jason_ |
That must be it, that's what I'm getting |
| 15:54 |
jason_ |
Should I be using an earlier opensrf? |
| 15:55 |
bshum |
Xenial support is only in the 2.5-alpha and master OpenSRF presently (so newer actually), but perhaps if it's not too late, I might suggest trying things out with Ubuntu 14.04 instead. |
| 15:55 |
bshum |
That's the more widely tested Ubuntu version at the moment. |
| 15:56 |
jason_ |
That's fine, I'll try it with ubuntu 14, thanks for your help! |
| 15:56 |
bshum |
No problem, good luck jason_! |
| 15:56 |
jason_ |
I appreciate it :) |
| 15:57 |
* bshum |
quotes from the downloads page, "For Ubuntu, please use the 14.04 64-bit LTS (long term support) Server release." |
| 16:01 |
Bmagic |
Has anyone got aquisitions marc->load item records to load with age protection? Can I manually insert rows into acq.provider_holding_subfield_map for asset.copy->age_protect ? |
| 16:06 |
jason_ |
First time setting up evergreen, should I be working from the documentation here: http://docs.evergreen-ils.org/2.11/ |
| 16:08 |
Dyrcona |
jason_: I'd recommend the documentation on the downloads page for the tarball or whatever you downloaded. |
| 16:08 |
Dyrcona |
There should be links to the README. |
| 16:09 |
Dyrcona |
If you're installing from a git checkout, then I recommend the README in the code. |
| 16:11 |
Dyrcona |
And, yeah, though xenial is the latest Ubuntu LTS, Evergreen is still experimental on it. |
| 16:11 |
jason_ |
Understood, I'll do that, I have not gotten to evergreen yet, was trying to set up dependencies |
| 16:13 |
Dyrcona |
If you're installing on xenial, I recommend using git and using the master branch from both OpenSRF and Evergreen. |
| 16:13 |
Dyrcona |
The next releases should support xenial: Evergreen 2.12 and OpenSRF 2.5. |
| 16:14 |
|
maryj joined #evergreen |
| 16:14 |
jason_ |
I switched to trusty, this is just a test install on a cloud server to see if it will work for a project |
| 16:15 |
Dyrcona |
OK. That should work. |
| 16:44 |
|
rlefaive joined #evergreen |
| 16:49 |
|
mixo joined #evergreen |
| 16:49 |
mixo |
hello |
| 16:50 |
mixo |
how can i change "minimum transit checkin interval" |
| 16:55 |
phasefx |
mixo: hi. You mean, where to find the setting? It's under Admin -> Local Admin -> Library Settings in the staff client |
| 17:00 |
mixo |
thank you |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:01 |
mixo |
when i try to abort transit it goes to "canceld transit" state |
| 17:01 |
mixo |
is this normal ? |
| 17:02 |
mmorgan |
mixo: Yes, as of 2.11 |
| 17:03 |
mmorgan |
lp 1613374 |
| 17:03 |
pinesol_green |
Launchpad bug 1613374 in Evergreen "Feature Request: "Canceled Transit" Item Status" [Wishlist,Fix released] https://launchpad.net/bugs/1613374 |
| 17:05 |
mixo |
but it is not goes available state after that |
| 17:06 |
mixo |
thank you |
| 17:07 |
|
mmorgan left #evergreen |
| 17:07 |
|
jvwoolf joined #evergreen |
| 17:10 |
|
Dyrcona joined #evergreen |
| 17:33 |
mixo |
sorry what means "item is in status canceled transit, additional staff action may be required"? |
| 17:33 |
mixo |
what can I do? |
| 17:38 |
mixo |
I want it to go to available state |
| 17:43 |
phasefx |
mixo: you can just check it in |
| 17:43 |
phasefx |
and the status will flip from Canceled Transit to Reshelving, assuming you check it in at the right library |
| 17:50 |
mixo |
when I check in it goes to "in transit state" |
| 17:54 |
phasefx |
mixo: that'll happen if the Circ Library for the item is different than the Workstation Library for your staff client |
| 18:01 |
mixo |
but I've loged in with admin user, and workstation library is top on the library tree |
| 18:03 |
phasefx |
mixo: that's not a good practice (both), but the workstation library being the top of the tree in particular is not good; you should pick a more specific library from the tree |
| 18:04 |
phasefx |
let's say your tree looks like this: CONS -> SYS1 -> BR1, and that all your items belong to BR1. You want to register the workstation at BR1, so that when you check in and out items, they'll know they're at BR1 |
| 18:05 |
mixo |
Ok, thank you |
| 18:05 |
phasefx |
if they think they're at CONS, they have no idea where they really are, since CONS is so abstract |
| 18:06 |
phasefx |
and they'll create transit records from CONS to wherever they belong |
| 18:06 |
phasefx |
you're welcome |
| 18:10 |
mixo |
Can I set "minimum transit chekin interval" to "1 hours"? |
| 18:13 |
phasefx |
you could |
| 18:13 |
phasefx |
that'll make an item stay in transit for at least one hour |
| 18:16 |
mixo |
thank you very much |
