| Time |
Nick |
Message |
| 05:13 |
|
jblyberg7 joined #evergreen |
| 07:40 |
|
redavis joined #evergreen |
| 08:00 |
|
BDorsey joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:51 |
|
dguarrac joined #evergreen |
| 09:12 |
|
Dyrcona joined #evergreen |
| 10:00 |
|
sandbergja joined #evergreen |
| 10:03 |
sandbergja |
berick: the redis branch in OpenSRF has a very small merge conflict with today's main. I resolved it and pushed to a new branch. Should I force-push the rebase to the collab branch as well? |
| 10:04 |
berick |
sandbergja: yes, please, that would be great. |
| 10:09 |
sandbergja |
hmmmm... I'm getting "hook declined". Maybe it doesn't allow others to force push over somebody else's collab branch? |
| 10:09 |
berick |
sandbergja: hm, yeah, probably |
| 10:09 |
berick |
got a branch I can pull from? |
| 10:09 |
sandbergja |
yeah, user/sandbergja/lp2017941-opensrf-on-redis-v3-rebased |
| 10:09 |
berick |
thanks |
| 10:11 |
Dyrcona |
sandbergja: Only the owner can force push to a collab branch. You can do a normal push, though, and as git maintainer, I'd prefer that. force pushes leave artifacts in the repository. |
| 10:11 |
sandbergja |
Dyrcona++ |
| 10:11 |
sandbergja |
thanks, that's good to know |
| 10:12 |
Dyrcona |
These dangling artifacts are supposed to be cleaned up periodically, but sometimes manual intervention is required. |
| 10:14 |
Dyrcona |
That said, force pushes in general are OK. |
| 10:19 |
berick |
sandbergja: branch updated. thanks for the heads up. |
| 10:19 |
sandbergja |
Thanks, berick! |
| 10:20 |
|
collum joined #evergreen |
| 10:27 |
Dyrcona |
I sometimes think our triggers are out of hand. I'm updating tcn_source on 10,000 bib records and according to ps it's using 16GB of RAM and 88% of a CPU on my test database. |
| 10:27 |
Dyrcona |
I'm pretty sure it's mostly being used by the maintain 901 trigger, which is actually why I am doing this. |
| 10:32 |
Dyrcona |
I wonder if using a transaction and deferring all triggers would help with the speed of this? |
| 10:36 |
Dyrcona |
Actually, it's probably smple rec and some of the other triggers, too. I'm not sure I want to disable simple rec in a transaction. I'll have to investigate the triggers a bit more. |
| 10:40 |
pinesol |
News from commits: LP1850473 (follow-up): Update DOM selector in nightwatch test <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=bddc372d27e4ac9298ef6d265534c3b14529b2a2> |
| 10:41 |
Dyrcona |
No, I don't want to disable any triggers. It would lead to locking and possible dead locks. Setting session replication role is overkill since it disables all triggers. |
| 10:45 |
Dyrcona |
Looks like the ingest triggers are getting fired, too, but they.... Oh wait. The marc changes.... |
| 10:53 |
Dyrcona |
Trying different batch sizes, with a limit on a subquery, It did 10 in 5 seconds 100 in 26 seconds and 1000 took 4 minutes 23 seconds and used a lot more memory. |
| 10:53 |
* Dyrcona |
tries 500. |
| 10:56 |
Dyrcona |
1m40.676s... |
| 10:56 |
Dyrcona |
i want to keep the batch run time under 1 minute if I can. |
| 11:02 |
|
sandbergja|2 joined #evergreen |
| 11:08 |
Dyrcona |
Think I'll try a batch in production. |
| 11:15 |
Dyrcona |
Hm. 530.105 seems rather long for an 'in' list, huh.... |
| 11:16 |
|
briank joined #evergreen |
| 11:19 |
Dyrcona |
My editor is having "fun" dealing with that file. |
| 11:26 |
Dyrcona |
Hm... It's taking around 1m 10s to update 200 in produciton right now. I did 2 batches so far. |
| 11:36 |
|
smayo joined #evergreen |
| 11:38 |
Stompro |
Anyone work with Orangeboy? They want access to the DB to pull their data... and I'm not loving that. |
| 11:54 |
Dyrcona |
Direct access to the database? I know what I'd tell them... |
| 11:54 |
Dyrcona |
Have you suggested the APIs, and setting up an account with appropriate permissions? |
| 11:55 |
|
sandbergja|2 joined #evergreen |
| 11:58 |
|
jihpringle joined #evergreen |
| 11:58 |
Stompro |
Re Orangeboy, just heard back from them, they will provide the SQL queries and we can just upload the results. Seems like a much better option. |
| 11:59 |
Dyrcona |
Stompro: That's where I thought it would go, actually. I'd be OK with that depending on the queries. |
| 12:00 |
Dyrcona |
Marketing, huh.... |
| 12:00 |
|
Dyrcona left #evergreen |
| 12:00 |
|
Dyrcona joined #evergreen |
| 12:01 |
Dyrcona |
oops. Ctrl-w in the wrong window. |
| 12:01 |
* Dyrcona |
pops out to grab some lunch. BRB. |
| 12:05 |
Stompro |
Anyone seeing Content Cafe issues this morning... I'm getting timeouts and 500 errors. |
| 12:10 |
jihpringle |
Stompro: not as far as I can tell from our catalogue, most titles seems to have cover art today, but I'll keep an eye on it |
| 12:14 |
mmorgan |
Stompro: I'm not seeing issues either at the moment. |
| 12:18 |
Stompro |
Thanks, I'll check in with them about it and see if it is just us. Our cataloger just mentioned the EDI orders haven't been confirmed for us in the last hour also. |
| 12:29 |
|
collum joined #evergreen |
| 12:29 |
|
collum joined #evergreen |
| 13:02 |
Stompro |
The content cafe issues seem like they are just on our end... I must have messed up the network or something. One little dns server change made this morning... probably is it. |
| 13:08 |
|
sandbergja|2 joined #evergreen |
| 13:11 |
pinesol |
News from commits: LP1983156: ng lint --fix <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4ed591ff157727d5475b1a117e596635f0b629a5> |
| 13:11 |
pinesol |
News from commits: LP1983156 Consolidate Unified Holdings preference, Make buttons more <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=885cb3fa019d2765238fa8a98bbc9febe8e26c8c> |
| 13:11 |
pinesol |
News from commits: LP#1983156 - Save Classification,Prefix and Suffix in Copy template <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=896420367ae8ed7f6596246677bd3218f76edd6e> |
| 13:11 |
pinesol |
News from commits: LP1983156 Remove logic to update only default values, assure call number fields are... <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=470f32a8da364acb5a5e6f6f2e38e375a23ec9a3> |
| 13:11 |
pinesol |
News from commits: LP1983156 Copy Template Apply Call Number Vals <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d72eeca19bffefdd70215f82c9a098bbb5d06b51> |
| 13:11 |
pinesol |
News from commits: LP1983156 Add the checkbox to include call number info in item templates to <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=eca14aa3f5e898ee20cfa273f72c0193353b51ec> |
| 13:21 |
Dyrcona |
"waiting" means we've got a dead lock situation, doesn't it? |
| 13:25 |
Dyrcona |
Someon'es trying to delete an old staff account, it looks like. |
| 13:27 |
Dyrcona |
--csv option to psql doesn't properly quote strings apparently. |
| 13:28 |
Dyrcona |
ha! I'm not paying enough attention. LibreOffice had a "from row" 1322 still set on the CSV import from the other day. |
| 13:30 |
Dyrcona |
The delete was attempted multiple times. |
| 13:59 |
csharp_ |
Dyrcona: waiting can be just waiting - becomes a deadlock when two processes start waiting on each other |
| 14:00 |
csharp_ |
but seems like a matter of time - I'm nervously watching a very slow parallel reingest on a test server and many of the PG procs are in "waiting" state |
| 14:01 |
csharp_ |
reingest began ~11:30 a.m. yesterday - a little over half done per the batch count |
| 14:07 |
Dyrcona |
csharp_: My case was nearly catastrophic. Cascading deadlocks stemming from a process trying to delete a staff account with thousands of owned records. It was acquisitions account. The person doing the delete tried it at least 3 more times after the first timed out in the client. |
| 14:10 |
Dyrcona |
This sort of thing used to happen so much in Horizon with Sybase, that I made a little GUI in Java to show me the deadlocked processes. From that I could identify the most likely culprit process. I could then click its row in the table, type Ctrl-k and that would send the Sybase equivalent of pg_cancel_backend. Every now and then, I consider adapting that to PostgreSQL and Evergreen. |
| 14:13 |
Dyrcona |
Looks like someone was also loading MARC order records at the same time. I may have clobbered their backend process, not sure. I tried to only cancel the delete_usr queries. |
| 14:23 |
Dyrcona |
Speaking of long-running processes my update of tcn_source on 530,105 bibs where it is '' has been running for 1day, 5 hours, and 27 minutes at this point. |
| 14:25 |
Dyrcona |
Fortunately, that is on a test system, or I'd have probably had to cancel it for deadlocks. |
| 14:29 |
|
smayo joined #evergreen |
| 14:58 |
|
jonadab joined #evergreen |
| 15:01 |
csharp_ |
Dyrcona: holy moly |
| 15:01 |
csharp_ |
we were discussing earlier at GPLS whether or not we could add a feature that fires someone if they do something ridiculous |
| 15:02 |
csharp_ |
Evergreen Disemployer? |
| 15:02 |
csharp_ |
open-ils.terminate |
| 15:14 |
Dyrcona |
I like that open-ils.terminate... |
| 15:17 |
Dyrcona |
csharp_: That big update is the one that I was mumbling about splitting up earlier today. Wel'll probably do 200 at a time every two minutes for about 3 days, and it should be done. |
| 15:19 |
|
kmlussier joined #evergreen |
| 16:24 |
Dyrcona |
Way too many triggers... |
| 16:34 |
|
jihpringle joined #evergreen |
| 16:50 |
Dyrcona |
We don't usually disable triggers during database upgrades, but in this case, it might be warranted. |
| 16:50 |
Dyrcona |
I don't think updating auto_renewal_remaing to 0 where it is null warrants the update trigger firing. |
| 17:03 |
|
mmorgan left #evergreen |
| 17:17 |
|
kmlussier left #evergreen |
| 18:05 |
|
jihpringle joined #evergreen |
| 18:25 |
|
sleary_ joined #evergreen |
