| Time |
Nick |
Message |
| 01:27 |
|
sandbergja joined #evergreen |
| 01:52 |
|
sandbergja joined #evergreen |
| 06:23 |
|
devted joined #evergreen |
| 06:24 |
|
akilsdonk joined #evergreen |
| 06:24 |
|
dbs joined #evergreen |
| 06:24 |
|
miker joined #evergreen |
| 06:24 |
|
csharp_ joined #evergreen |
| 06:25 |
|
ericar joined #evergreen |
| 06:25 |
|
rhamby joined #evergreen |
| 06:25 |
|
abneiman joined #evergreen |
| 06:25 |
|
drigney joined #evergreen |
| 06:25 |
|
jgoodson joined #evergreen |
| 06:25 |
|
phasefx_ joined #evergreen |
| 06:26 |
|
jyorio joined #evergreen |
| 06:26 |
|
jeff_ joined #evergreen |
| 06:29 |
|
eady joined #evergreen |
| 06:55 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:34 |
|
csharp joined #evergreen |
| 08:06 |
|
bos20k joined #evergreen |
| 08:25 |
|
Dyrcona joined #evergreen |
| 08:34 |
|
aabbee joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 09:08 |
Dyrcona |
Syrup apparently doesn't play nice with our nginx proxy setup, though it could be timing out for other reasons. I resolved the issue by pointing it at a utility server that runs Apache with Evergreen for Z39.50/SRU. |
| 09:10 |
|
yboston joined #evergreen |
| 09:20 |
|
jvwoolf joined #evergreen |
| 09:20 |
Dyrcona |
Bugs leading to data loss: Should these be Critical or High importance? I guess it depends on the severity of the data loss. |
| 09:25 |
csharp |
I would say critical if it leads to data loss |
| 09:25 |
mmorgan |
Any data loss sounds critical to me |
| 09:26 |
csharp |
and let someone else downgrade it as they see fit |
| 09:29 |
Dyrcona |
Lp 1840669 if either of you want to bump the importance from High to Critical. |
| 09:29 |
pinesol |
Launchpad bug 1840669 in Evergreen 3.3 "Aging Circulations Removes Auto-Renewal Information" [High,Confirmed] https://launchpad.net/bugs/1840669 |
| 09:30 |
Dyrcona |
Also, if you feel like bumping the importance of Lp 1835577 that would be fine with me. I'm not sure how important it is, since I don't do reports, myself. |
| 09:30 |
pinesol |
Launchpad bug 1835577 in Evergreen 3.3 "Combined Aged and Active Circulations Report Source not Exposed to Auto-Renewal Fields" [Undecided,Confirmed] https://launchpad.net/bugs/1835577 |
| 09:33 |
Dyrcona |
I also have a branch for Lp 1839002 but haven't added it to the bug, yet, because we haven't tested it. I plan to install it on training at the end of the day today. |
| 09:33 |
pinesol |
Launchpad bug 1839002 in Evergreen "auto_renewal field stored as NULL/TRUE. Should be FALSE/TRUE" [High,In progress] https://launchpad.net/bugs/1839002 - Assigned to Jason Stephenson (jstephenson) |
| 09:33 |
Dyrcona |
It takes a while to update the existing fields. |
| 09:34 |
Dyrcona |
I will likely have something for Lp 1835085 by lunch time. |
| 09:34 |
pinesol |
Launchpad bug 1835085 in Evergreen "Autorenewal sets both desk_renewal and auto_renewal to TRUE for new circ" [Medium,In progress] https://launchpad.net/bugs/1835085 - Assigned to Jason Stephenson (jstephenson) |
| 09:35 |
Dyrcona |
I think the above are good candidates for bug squashing week. :) |
| 09:35 |
mmorgan |
Dyrcona++ |
| 09:41 |
|
yboston joined #evergreen |
| 09:44 |
csharp |
Dyrcona++ |
| 09:45 |
csharp |
(and I agree with the "High" priority for that one) |
| 09:49 |
|
Stompro joined #evergreen |
| 09:59 |
|
jvwoolf joined #evergreen |
| 09:59 |
|
sandbergja joined #evergreen |
| 10:19 |
|
berick joined #evergreen |
| 10:54 |
Dyrcona |
What does everything about removing an api in a bug fix. I think this api (open-ils.circ.renew.auto) was added as a result of misunderstanding. The feature could easily have been implemented with an auto_renewal flag, the same way that sip_renewal and opac_renewal work. |
| 11:02 |
* Dyrcona |
"deprecates" it.... |
| 11:02 |
|
bos20k joined #evergreen |
| 11:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:22 |
|
bos20k joined #evergreen |
| 11:43 |
|
yboston joined #evergreen |
| 11:49 |
|
jihpringle joined #evergreen |
| 12:29 |
|
Christineb joined #evergreen |
| 12:30 |
|
yboston joined #evergreen |
| 12:32 |
gsams |
Dyrcona: I was going to ask today about an autorenewal issue I'm seeing in my library, where when an item is autorenewed for a patron with a different home library it reverts to their home library's policy which is not how we handle it here. |
| 12:32 |
gsams |
I've been unable to really spend a lot of time on it, but it is causing some issues for us as not everyone has autorenewal enabled. |
| 12:34 |
gsams |
Could the desk_renewal issue be related in some way? |
| 12:35 |
jeff |
there is a setting which determines if a renewal uses policies of the original circ's circ_lib or the user's home_ou. is your issue that you see auto-renewals not respecting that setting? |
| 12:36 |
mmorgan |
gsams: What jeff said. It's a Global Flag. |
| 12:36 |
mmorgan |
Circ: Use original circulation library on opac renewal instead of user home library |
| 12:37 |
mmorgan |
Using home library doesn't make any sense for us. |
| 12:39 |
gsams |
jeff++ |
| 12:39 |
gsams |
mmorgan++ |
| 12:39 |
gsams |
TIL about that global flag which is currently set to false. |
| 12:43 |
mmorgan |
gsams: Setting that flag to true will cause action.circulation.circ_lib to get the value of action.circulation.circ_lib from the parent circulation of the renewal for all renewals. Just mentioning this because it could affect circ counts - depending on how you count. |
| 12:53 |
gsams |
Thanks for the heads up, our consortium started out with honoring home library policies and switched about a year in, but clearly weren't aware of this flag. I'll definitely be discussing this with everyone. |
| 13:03 |
|
jvwoolf left #evergreen |
| 13:12 |
|
yboston joined #evergreen |
| 13:16 |
Dyrcona |
gsams: To be clear, auto renewal and OPAC renewal are doing the same thing, so changing the setting for the OPAC renewals affects auto renewals. I was mildly surprised when I saw that in the code this morning, but none of my patches change that behavior. |
| 13:22 |
* mmorgan |
realizes she misspoke earlier regarding "all renewals". Should have read *opac* renewals |
| 13:25 |
* Dyrcona |
has a branch for that ready, too, but will wait to push it until after we've tested it. May be typos, etc. |
| 13:26 |
Dyrcona |
By "push it" I mean to the working repo. |
| 13:30 |
|
khuckins joined #evergreen |
| 13:34 |
|
yboston joined #evergreen |
| 13:57 |
|
yboston joined #evergreen |
| 13:59 |
miker |
berick: have you seen any trouble using a single (non-"xact=>1") cstore editor with many xact_begin/xact_commit pairs, like in a loop? it's acting like it refuses to receive data after the first xact_commit... |
| 14:01 |
berick |
miker: hm, no, I can't say that I have |
| 14:03 |
Dyrcona |
miker: I haven't either, and I've got a script I run with some frequency that does exactly that, then disconnects in the END {} |
| 14:04 |
miker |
I haven't had problems either, but now... |
| 14:07 |
Dyrcona |
Oh... I'm using xact_begin and commit, not xact_commit... |
| 14:07 |
Dyrcona |
That's why I disconnect at the end. |
| 14:07 |
miker |
ah, maybe that's my issue right there |
| 14:07 |
Dyrcona |
Well, xact_begin and xact_commit should work. |
| 14:08 |
Dyrcona |
I just figured why reconnect in a loop. |
| 14:14 |
berick |
Dyrcona: ->commit does disconnect |
| 14:14 |
berick |
->commit == xact_commit + disconnect |
| 14:14 |
Dyrcona |
berick: I thought it was the other way 'round.... |
| 14:15 |
Dyrcona |
Guess, I'll have to check the code, again..... |
| 14:16 |
* Dyrcona |
gets confused with all the stuff to remember. :) |
| 14:19 |
Dyrcona |
For the logs, berick is correct commit disconnects and xact_commit doesn't...But a disconnect with no connection ends up being harmless. |
| 14:19 |
Dyrcona |
Maybe I'll remember it for another year or so, then forget again. :) |
| 14:23 |
* Dyrcona |
sings along with Sting... "Too much information...." :) |
| 14:34 |
miker |
bah... IDL error, bad sequence name |
| 14:34 |
miker |
(for the logs) |
| 14:35 |
Dyrcona |
:) |
| 14:38 |
* Dyrcona |
switches the script from commit and rollback to xact_commit and xact_rollback. |
| 14:53 |
|
khuckins joined #evergreen |
| 15:18 |
Dyrcona |
Hmmm... We're getting the following errors on our training server after updating to 3.2.8: |
| 15:18 |
Dyrcona |
2019-08-30 15:06:46.034 EDT [6751] evergreen evergreen ERROR: null value in column "id" violates not-null constraint |
| 15:18 |
Dyrcona |
2019-08-30 15:06:46.034 EDT [6751] evergreenevergreen DETAIL: Failing row contains (null, 1759509, opac.hold_notify, "phone:email"). |
| 15:18 |
|
jihpringle joined #evergreen |
| 15:18 |
Dyrcona |
That's on the actor.usr_setting table of course. I'm wondering if anyone else has seen this. |
| 15:20 |
Dyrcona |
Um... Our table lost its sequence.... |
| 15:21 |
csharp |
Dyrcona: not seeing that in my logs today, FYI |
| 15:21 |
Dyrcona |
csharp: Thanks. I think it's something local, though I didn't do anything to the table, myself. |
| 15:21 |
* Dyrcona |
checks the ugprade script just to make sure. |
| 15:22 |
Dyrcona |
Our actor.usr_setting table on training has no sequence or primary key, so something happened. |
| 15:23 |
* Dyrcona |
scratches his head. |
| 15:24 |
rhamby |
Dyronca: blame chinese hackers, they love to randomly remove primary keys |
| 15:24 |
* rhamby |
can not support this with evidence |
| 15:24 |
csharp |
@blame chinese checkers |
| 15:24 |
pinesol |
csharp: Your failure is now complete, chinese checkers. |
| 15:25 |
Dyrcona |
But, the database is not supposed to be exposed and command line access is supposed to require a private key. I suppose I should double check those things. |
| 15:31 |
|
jvwoolf joined #evergreen |
| 15:35 |
Dyrcona |
Hmm... The table is created with data bype of bigserial. If I try to alter the column to that type, I get ERROR: type "bigserial" does not exist |
| 15:35 |
Dyrcona |
I guess I have to recreate the sequence manually? |
| 15:42 |
|
mcgriff joined #evergreen |
| 15:42 |
|
jvwoolf1 joined #evergreen |
| 15:43 |
Dyrcona |
That was a lot of supposes.... :) |
| 15:49 |
Dyrcona |
Apache config looks good and I can't access phppgadmin unless I'm using the VPN. |
| 15:52 |
Dyrcona |
hmmm.. |
| 15:52 |
|
gryffonophenomen joined #evergreen |
| 15:53 |
|
gryffonophenomen joined #evergreen |
| 15:55 |
jeff |
Dyrcona: serial, smallserial, and bigserial are all create-time shortcuts, they can't be used with ALTER. |
| 15:55 |
Dyrcona |
Remote psql connections timeout, and ssh config looks good. |
| 15:56 |
Dyrcona |
jeff: I kind of figured that out. I used bigint, 'cause it was just int. |
| 15:56 |
jeff |
you might need to adjust the sequence, which i don't know offhand if you can do without first dropping it. |
| 16:01 |
Dyrcona |
Sequence was gone apparently, but I'm still getting the null constraint errors. I may just drop the table and recreate it. |
| 16:07 |
jeff |
if the original sequence was dropped, the DEFAULT clause on the column went with it. you'd need to ALTER TABLE to set the default for the column to reference the new sequence, even if it has the same name as the previous sequence. |
| 16:07 |
Dyrcona |
jeff: too late. I did the destructive thing and lost all of the settings. |
| 16:15 |
Dyrcona |
jeff: I actually don't see how I would know from looking at the schema what default to set. |
| 16:16 |
Dyrcona |
Ah, wait, now I see it. |
| 16:16 |
jeff |
also a good idea to set the column that owns the serial |
| 16:17 |
Dyrcona |
Oh, nice... |
| 16:17 |
jeff |
(unless you don't want/care to because of multi-use of the serial or something...) |
| 16:17 |
Dyrcona |
The table in training now has no columns.... |
| 16:17 |
Dyrcona |
according to PgAdmin. |
| 16:18 |
Dyrcona |
jeff: I set owned by. |
| 16:19 |
Dyrcona |
create sequence actor.usr_setting_id_seq start with 2617168 owned by actor.usr_setting.id; |
| 16:20 |
Dyrcona |
Two refreshes later, and it looks right. Disappeared after the first refresh. pgadmin-- |
| 16:20 |
Dyrcona |
Though maybe running it over a ssh tunnel has something to do with it. :) |
| 16:21 |
Dyrcona |
What I'd like to know is how this happened in the first place, and I'm not ready to blame Chinese hackers. |
| 16:24 |
jeff |
set log_statement to ddl or higher for next time if it's not set that way already? |
| 16:27 |
jeff |
if you're archiving WAL files on the instance in question you could step back in time (binary search might help) and narrow down WHEN it happened. |
| 16:28 |
jeff |
you could reproduce the steps that got you to this point and see where things went amiss. |
| 16:28 |
jeff |
no common "my sequence didn't restore properly" gothas come to mind if this was a pg_dump/pg_restore |
| 16:29 |
Dyrcona |
jeff: That's all too much work for a training server and others have access to the database legitmately, and WAL archives, IIRC. |
| 16:30 |
jeff |
you could also potentially narrow down when the column went missing by identifying the time frame between the first errors on the table and the last known successful insert on the table. That might be tricky if there isn't a clear way to distinguish between operations that required an INSERT vs UPDATE, since only the INSERTs would have been failing. |
| 16:36 |
miker |
Dyrcona: and, of course, keep an eye on that db for (pg) catalog corruption ... that would be my first fear, unless superuser access is handed out like candy. |
| 16:36 |
Dyrcona |
There isn't. All I know is I was told it happened since I updated to 3.2.8 yesterday. No one uses this thing that much. |
| 16:37 |
* Dyrcona |
calls it a week and hopes to actually have a long weekend for a change. |
| 16:38 |
Dyrcona |
miker: It's not exactly candy, but everyone knows the password, so... |
| 16:39 |
jeff |
from what version to 3.2.8? version upgrade scripts or individual upgrade scripts? |
| 16:39 |
Dyrcona |
I'm inclined to blame someone poking around with commands that they shouldn't have rather than a bug. Though it could be failing drives. |
| 16:39 |
Dyrcona |
3.2.5 to 3.2.8 |
| 16:39 |
Dyrcona |
So, nothing big. |
| 16:40 |
jeff |
yeah, and nothing that obviously touches that table/serial. |
| 16:41 |
jeff |
@decide curiosity or corruption |
| 16:41 |
pinesol |
jeff: go with corruption |
| 16:41 |
jeff |
drat. |
| 16:41 |
Dyrcona |
:) |
| 16:45 |
Dyrcona |
Maybe I'll wipe the partition, initdb, and restore a dump next week. |
| 16:46 |
Dyrcona |
Well, have a nice weekend, everyone! |
| 16:46 |
|
sandbergja joined #evergreen |
| 17:06 |
|
mmorgan left #evergreen |
| 18:45 |
|
sandbergja joined #evergreen |
| 19:30 |
|
sandbergja joined #evergreen |
| 20:13 |
|
sandbergja joined #evergreen |
| 20:23 |
|
sandbergja joined #evergreen |
| 22:19 |
|
sandbergja joined #evergreen |
| 23:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
