Time |
Nick |
Message |
00:03 |
|
sandbergja_ joined #evergreen |
01:37 |
|
sandbergja_ joined #evergreen |
01:47 |
|
sandbergja_ joined #evergreen |
02:05 |
|
sandbergja_ joined #evergreen |
02:41 |
|
jvwoolf joined #evergreen |
04:47 |
pinesol |
News from qatests: Failed Installing OpenSRF pre-requisites <http://testing.evergreen-ils.org/~live//archive/2020-08/2020-08-05_04:00:03/test.7.html> |
05:28 |
|
agoben joined #evergreen |
07:16 |
|
rjackson_isl_hom joined #evergreen |
07:27 |
|
rfrasur joined #evergreen |
07:41 |
|
collum joined #evergreen |
07:54 |
|
angelo joined #evergreen |
08:07 |
|
alynn26 joined #evergreen |
08:08 |
|
mantis1 joined #evergreen |
08:43 |
|
mmorgan joined #evergreen |
09:06 |
|
Dyrcona joined #evergreen |
09:15 |
Bmagic |
@coffee [someone] |
09:15 |
* pinesol |
brews and pours a cup of Colombia Granja La Esperanza Geisha, and sends it sliding down the bar to felicia |
09:15 |
Bmagic |
@coffee [someone] |
09:15 |
* pinesol |
brews and pours a cup of Rusty's Hawaiian Red Caturra Natural, and sends it sliding down the bar to mmorgan |
09:15 |
Bmagic |
@coffee [someone] |
09:15 |
* pinesol |
brews and pours a cup of Kenya Thiriku Top Auction Lot, and sends it sliding down the bar to jeff__ |
09:15 |
Bmagic |
@coffee [someone] |
09:15 |
* pinesol |
brews and pours a cup of Kenya Nyeri AB Gichatha-ini Signature Series, and sends it sliding down the bar to abneiman |
09:16 |
Bmagic |
I might be going a little stir crazy these days, isolated at home. I've always got pinesol! |
09:16 |
mmorgan |
Bmagic: Thank you! |
09:17 |
abneiman |
Bmagic++ |
09:17 |
Bmagic |
yay! coffee FTW |
09:17 |
Bmagic |
I'm having some Brazil Rose Diamond myself |
09:18 |
Bmagic |
from my local roaster: https://www.fretboardcoffee.com/shop/brazil-rose-diamond |
09:18 |
Bmagic |
and now business: |
09:18 |
Bmagic |
Has anyone else wrestled with "cannot write to DB" when renewing via OPAC? Found the error on the DB: "invalid input syntax for type timestamp with time zone: "2020-08-04 23:59:59 <-04>+04"" |
09:23 |
Bmagic |
I'm thinking it's happening in action.push_circ_due_time() |
09:24 |
Bmagic |
probably stemming from actor.org_unit_ancestor_setting('lib.timezone' |
09:24 |
csharp |
maybe a typo in the setting? |
09:25 |
Bmagic |
select * from actor.org_unit_setting where name='lib.timezone' 0 results |
09:26 |
csharp |
I would look at activity.log for what the actual call is |
09:27 |
csharp |
(assuming you segregate your logs like we do) |
09:31 |
Bmagic |
I've got the logs. The osrfsys log doesn't look unusual. |
09:34 |
csharp |
hmm |
09:34 |
Bmagic |
pasting in pastebin |
09:40 |
Bmagic |
https://pastebin.com/TSQqNEW4 |
09:41 |
|
jvwoolf joined #evergreen |
09:45 |
Bmagic |
There is more to it than that but I think that's the relevant piece. In case it's not. Here's more: https://pastebin.com/TFusXukB |
09:47 |
Bmagic |
And the PG error: https://pastebin.com/64W1uXRf |
09:52 |
csharp |
Bmagic: what does "show timezone;" show? |
09:52 |
mmorgan |
Odd that the due date is 2020-08-04T00:59:59-0400 rather than 2020-08-04T23:59:59-0400 |
09:53 |
Bmagic |
America/New_York |
09:53 |
csharp |
is that correct for you? |
09:53 |
Bmagic |
yep |
09:53 |
* csharp |
assumed it would be America/Chicago |
09:56 |
Dyrcona |
rhamby: Won't Fix works for "was valid but isn't any longer." It doesn't fit in with current project plans, though a "Fixed Elsewhere" status could be more what is need. |
09:59 |
csharp |
Bmagic: https://pastebin.com/cQtyfgPH is the source code for that - looks like it sets whatever the incoming due date is to that date + 1 day - 1 second |
09:59 |
Bmagic |
right, somehow that code is producing invalid SQL (I think) |
10:04 |
rhamby |
Dyrcona : I like the idea of a "Fixed Elsewhere" but it may be too sidecase to worry about /shrug I have an irrational instinct to have everything fit the boxes they are in |
10:12 |
csharp |
Bmagic: this should simulate what that function did with that timestamp: |
10:12 |
csharp |
select (('2020-08-04T00:59:59-0400' AT TIME ZONE current_setting('timezone'))::DATE + '1 day'::INTERVAL - '1 second'::INTERVAL || ' ' || current_setting('timezone'))::TIMESTAMPTZ; |
10:13 |
csharp |
2020-08-04 23:59:59-04 is what I get |
10:13 |
Bmagic |
yeah, looks sane to me.... what in the world could have caused that DB error.... |
10:13 |
Bmagic |
oh wait - I get an error from your query |
10:14 |
csharp |
same error? |
10:14 |
Bmagic |
yep! |
10:14 |
Bmagic |
select current_setting('timezone'); |
10:14 |
Bmagic |
gives me: "<-04>+04" !!! |
10:14 |
csharp |
aha! |
10:15 |
Bmagic |
now we are getting somewhere |
10:15 |
Bmagic |
csharp++ |
10:15 |
Bmagic |
now.... how is this possible |
10:17 |
Bmagic |
from postgresql.conf: log_timezone = 'America/New_York' |
10:17 |
berick |
returns 'America/New_York' when I test |
10:17 |
Bmagic |
looking at another config, perhaps it should be: log_timezone = 'localtime' |
10:17 |
csharp |
from the docs, show timezone is equivalent to current_setting('timezone')::text |
10:18 |
berick |
though I do like the idea of living in '<-04>+04' |
10:18 |
csharp |
Bmagic: timezone, not log_timezone |
10:18 |
Bmagic |
ah yes |
10:18 |
Bmagic |
timezone = 'America/New_York' |
10:18 |
csharp |
berick: maybe that's the glitch that caused 2020!!! |
10:19 |
csharp |
<astronaut_with_gun>Always has been</astronaut_with_gun> |
10:19 |
berick |
heh |
10:21 |
csharp |
troubleshooting Bmagic's issue is way more fun that what I'm supposed to be doing :-) |
10:21 |
csharp |
not fun for Bmagic of course |
10:22 |
Bmagic |
so weird - show timezone; and select current_setting('timezone'); produce the same result. But if I login with the evergreen user, it's different.... |
10:22 |
Bmagic |
csharp: I'm not stressed in the least. I appreciate your hlep! |
10:22 |
Bmagic |
help |
10:22 |
csharp |
Bmagic: always happy to help |
10:25 |
Bmagic |
so - the postgres user gives me the "right" answer to select current_setting('timezone'); |
10:25 |
Bmagic |
the evergreen user gives me the strange <-04>+04 |
10:25 |
Bmagic |
I think I know what to do |
10:32 |
csharp |
https://stackoverflow.com/questions/6663765/postgres-default-timezone has some useful information |
10:32 |
Bmagic |
lol - same article I was readaing |
10:33 |
Bmagic |
google++ |
10:33 |
csharp |
SELECT * FROM pg_timezone_names where abbrev = '<-04>+04'; |
10:33 |
csharp |
maybe? |
10:33 |
Bmagic |
0 rows |
10:34 |
csharp |
maybe play with ~ or like |
10:34 |
csharp |
(or visually scan the list on the screen :-) ) |
10:34 |
Bmagic |
SELECT * FROM pg_timezone_names where abbrev ~ '04'; |
10:34 |
Bmagic |
gives results, none of them resemble that weird zone expression |
10:48 |
Bmagic |
the timezone is set per session. It takes a cue from postgresql.conf timezone setting as default (I think) and for some reason, timezone = 'America/New_York' is the issue |
11:03 |
csharp |
Bmagic: what happens when you do: SET timezone TO DEFAULT; then select current_setting('timezone'); |
11:03 |
Bmagic |
did that, same issue |
11:03 |
csharp |
hmm |
11:04 |
csharp |
show timezone_abbreviations ; |
11:04 |
Bmagic |
one row: Default |
11:04 |
csharp |
same here |
11:05 |
Dyrcona |
Bmagic: Perhaps you should take your questions to #postgresql? |
11:05 |
|
sandbergja joined #evergreen |
11:05 |
Bmagic |
I'm thinking I need to change the config to: timezone = 'localtime' and restart |
11:05 |
Dyrcona |
Bmagic: I'm not so sure of that. |
11:05 |
Bmagic |
at least, that's my current plan |
11:05 |
Bmagic |
I'll check with #postgresql |
11:07 |
Bmagic |
1000+ Nicks in that channel, wowsers PG rocks |
11:09 |
|
sandbergja joined #evergreen |
11:09 |
Dyrcona |
Yes, I often go there first for my PostgreSQL questions. |
11:09 |
Dyrcona |
When I'm confident it is not an Evergreen thing, that is. |
11:10 |
Dyrcona |
I'll join you in case you want some solidarity. |
11:11 |
Dyrcona |
Just like in here, be patient. Also, they tend to get upset with long monologues. Try to put as much on one line as you can and be concise. |
11:12 |
Bmagic |
right on |
11:21 |
Dyrcona |
And, maybe no one knows the answer. I'm starting to think it is something in your environment and not so much a PostgreSQL issue. |
11:21 |
berick |
Bmagic: yay, they finally have a dev release of elasticsearch v7 for Perl -- https://github.com/elastic/elasticsearch-perl/releases/tag/version_7.30_1 -- i'll look at that before too long |
11:22 |
Bmagic |
oh baby |
11:41 |
|
nfBurton joined #evergreen |
11:44 |
|
jvwoolf1 joined #evergreen |
11:45 |
|
nfBurton71 joined #evergreen |
11:45 |
|
collum joined #evergreen |
11:47 |
Bmagic |
Dyrcona (and csharp and everyone else) - ALTER USER evergreen reset timezone; |
11:47 |
Bmagic |
thanks #postgresql |
11:52 |
|
sandbergja_ joined #evergreen |
11:58 |
|
sandbergja_ joined #evergreen |
12:05 |
|
jihpringle joined #evergreen |
12:06 |
|
rjackson_isl_hom joined #evergreen |
12:16 |
csharp |
Bmagic++ # interesting |
12:30 |
|
mrisher joined #evergreen |
12:30 |
|
mrisher joined #evergreen |
12:33 |
Dyrcona |
depesz++ |
12:34 |
Dyrcona |
He reviewed the Evergreen schema and did some performance testing once before. |
12:34 |
Dyrcona |
Bmagic++ |
12:37 |
Bmagic |
I remember that! I was excited to meet someone famous, albiet IRC |
12:38 |
Bmagic |
again - a video clip comes to mind: https://www.youtube.com/watch?v=v3AucZOsjZ4 |
12:39 |
Dyrcona |
Bmagic: I get very different output with the select * from pg_db_role_setting or \drds than you posted in #postgresql. |
12:39 |
Bmagic |
whoops, that wasn't in English. Here it is: https://www.youtube.com/watch?v=811z3ktTh-U |
12:40 |
Dyrcona |
I don't have the path or timezone deliberately set for the evergreen user. |
12:40 |
Dyrcona |
Yeah, depesz runs the explain site and s a few others. |
12:41 |
Dyrcona |
16401 | 0 | {log_lock_waits=1} |
12:42 |
Dyrcona |
I suspect that you did something, or ran something in your database at some point to set the user path and the timezone. |
12:44 |
Bmagic |
holy cow - this got me laughing https://www.youtube.com/watch?v=b2cauVuJsJE |
12:45 |
Bmagic |
Dyrcona: yeah, I'm not really sure how this PG setting got set but I'm glad we found it! I can only imagine it's been plaguing the system |
12:46 |
Dyrcona |
I'll watch those later when I have my earbuds plugged into the laptop. |
12:49 |
Dyrcona |
Well, it's in the 0757 upgrade script that you shared a link to in #postgresql. I wonder why I don't have it, unless we missed that update or unset it later. |
12:50 |
Bmagic |
yeah, not sure either |
12:50 |
Bmagic |
that was one of two places I found it in the source |
12:50 |
Bmagic |
looks like it was in wrapped into 2.4 upgrade script |
12:51 |
Bmagic |
but a fresh install of EG (no upgrade scripts) seems to set it like this: "SET search_path = public, pg_catalog;" - excerpted from 000.english.pg..... script |
13:08 |
Dyrcona |
I don't think it is necessary to add either to the path, and if your user is evergreen, you don't have to add evergreen, either. |
14:40 |
|
jvwoolf joined #evergreen |
15:00 |
|
sandbergja joined #evergreen |
15:03 |
|
sandbergja_ joined #evergreen |
15:04 |
|
sandbergja joined #evergreen |
15:19 |
|
sandbergja joined #evergreen |
15:22 |
|
sandbergja joined #evergreen |
15:32 |
|
mantis1 left #evergreen |
15:37 |
|
jihpringle joined #evergreen |
15:47 |
|
jvwoolf1 joined #evergreen |
15:50 |
|
angelo joined #evergreen |
15:51 |
angelo |
is there anywhere i can find a copy of the EG v3.2 database structure? |
15:55 |
rhamby |
angelo : have you cloned the source from git? |
15:55 |
rhamby |
the files are in it or are you looking for something like a diagram? |
15:55 |
angelo |
a diagram |
15:56 |
angelo |
i need to compare the differences between 3.2 and 3.4 |
15:56 |
rhamby |
no, that'd be pretty messy. actor.usr links to dozens of tables easily. |
15:56 |
rhamby |
a number of tables have a lot of links so you could do a visual representation but to make it meaningful you'd have to break it up into subsections |
15:57 |
angelo |
im trying to import tsv files from a 3.2 install into a 3.4 install but i think the structure is different |
15:57 |
mmorgan |
angelo: There's a representation here: http://docs.evergreen-ils.org/3.2_schema/ |
15:57 |
rhamby |
it might be, you can look at the upgrade scripts to see what changed |
15:58 |
Dyrcona |
angleo: Import into a 3.2 schema and then upgrade after. |
15:58 |
Bmagic |
rhamby angelo: what about a git diff between the fm_IDL.xml on the two git branches? |
15:58 |
rhamby |
looking at the upgrade scripts would be faster than manually comparing schemas |
15:58 |
Bmagic |
oh well - yeah, the root of the reason why is probably better addressed than "how" |
15:58 |
rhamby |
Bmagic: assuming the changes made it into field mapper :) but yeah, seems like a valid idea |
15:59 |
Dyrcona |
Functions change more often than table definitions. |
15:59 |
rhamby |
Dyrcona's suggestion seems valid to me too |
15:59 |
angelo |
dyrcona can i use the 3.2 schema on the 3.4 install? or do i need to install a whole new server? |
15:59 |
rhamby |
yeah, and if I remember this is one of the migration-tools exports so it's the major tables, actor.usr, biblio.record_entry etc.... |
15:59 |
Bmagic |
angelo: yep - setup an EG 3.2 server - do your migration, then upgrade |
16:00 |
Dyrcona |
Just rebuild the database with the 3.2 setup script, then upgrade the database. You can leave the 3.4 code installed on the server. |
16:02 |
Bmagic |
rhamby: I just wrote you an email then popped over to IRC and saw you were here.... sorry 'bout that |
16:02 |
Dyrcona |
Well, I missed a step: reinitialize the database with the 3.2 script, load your data, and then upgrade afterward. If your data is from 3.2 that might be easier. |
16:03 |
angelo |
dyrcona where can i find that setup script? |
16:04 |
rhamby |
Bmagic: np, I can type my reply here. BMagic not at this point but we might move it over to github at some point, for now if you have a patch feel free to send it to me |
16:05 |
Dyrcona |
angelo: Open-ILS/src/support-scripts/eg_db_config |
16:05 |
Bmagic |
rhamby: I have one - though I might need to figure out how to squash three local non-consecutive commits and then createa a patch file..... |
16:06 |
Dyrcona |
If you check out 3.2 or a download a 3.2 tarball, drop the existing database, and then run the eg_db_config from 3.2, you'll get a 3.2 schema installed. |
16:06 |
rhamby |
Bmagic yeah just send it whenever you can |
16:06 |
Bmagic |
rhamby: found it git format-patch cc1dde0dd^..6de6d4b06 --stdout > foo.patch - aint google grand |
16:07 |
angelo |
yeah i only see 3.5 and 3.4 tarballs on the site |
16:07 |
rhamby |
I search for stuff all the time, anyone who doesn't ... is either lying or well, probably lying. |
16:07 |
rhamby |
I guess they could have a very narrow set of job duties .... |
16:08 |
Dyrcona |
angelo: I'd recommend git over a tarball, but if you copy the link location for the 3.4 or 3.5 tarball and change the numbers, you should get the 3.2 tarball. |
16:08 |
Dyrcona |
We don't delete them from the server, just hide them. |
16:08 |
angelo |
got it |
16:13 |
Bmagic |
rhamby: sent it - So here's the deal. I'm embarking on another collectionHQ quest - and will be making more edits to this repo.... might be nice if this patch were in master. I know, it's selfish. |
16:13 |
Dyrcona |
Sharing is selfish? |
16:13 |
Dyrcona |
:) |
16:14 |
Bmagic |
rhamby: also - I realize that the patch I emailed you created a file called: 655.patch. I put that in my repo as a reminder to submit it to you. lol. You can delete that after the merge |
16:14 |
rhamby |
Bmagic I have to bail as it's game night but it's top of my inbox so I'll look first thing in the AM |
16:14 |
rhamby |
ok :) |
16:14 |
Bmagic |
no worries! |
16:14 |
Bmagic |
rhamby++ |
16:14 |
Dyrcona |
game_night++ |
16:14 |
Bmagic |
game_night++ |
16:16 |
Dyrcona |
Well, the 655.patch should be easy to remove from the patch file before the merge if it is an all-new file. |
16:16 |
Bmagic |
it is all new |
16:17 |
Dyrcona |
Just open the patch in an editor and cut the block for that file. |
16:17 |
Bmagic |
It's very "matrix" - the patch file I sent him, creates another file in the repo for patching git.... but don't run that one :) just the one I emailed <- rhamby |
16:17 |
Dyrcona |
git apply won't know the difference, neither will patch, or git am for that matter. |
16:18 |
Bmagic |
Dyrcona: I considered this just before I clicked send. I wasn't sure enough about the syntax as to where to cut the lines from the patch file, and decided to take this route, explaining it to him here :) |
16:19 |
Dyrcona |
Well, it's usually pretty obvious where sections for files begin in a patch. |
16:19 |
Bmagic |
I wasn't 100% and didn't want to break the patch file |
16:20 |
Dyrcona |
Lines that resemble these: |
16:20 |
Dyrcona |
diff --git a/Open-ILS/xul/staff_client/server/OpenILS/symbol_overlay.xul b/Open-ILS/xul/staff_client/server/OpenILS/symbol_overlay.xul |
16:20 |
Dyrcona |
index 77b593eca7..33414f2912 100644 |
16:20 |
Dyrcona |
--- a/Open-ILS/xul/staff_client/server/OpenILS/symbol_overlay.xul |
16:20 |
Dyrcona |
+++ b/Open-ILS/xul/staff_client/server/OpenILS/symbol_overlay.xul |
16:21 |
Dyrcona |
rhamby will figure it out, either way. |
16:22 |
* Dyrcona |
messes with patches all the time. |
16:24 |
Dyrcona |
I'm pretty sure that a new file will have "-- a/dev/null" instead of the filename for the "old" version. |
16:24 |
Bmagic |
cool! |
16:24 |
Dyrcona |
You edited the patch? |
16:24 |
Bmagic |
nope, I already sent him the one that includes that new file that he can promptly delete |
16:25 |
Dyrcona |
:) |
16:25 |
Bmagic |
it's a patch within a patch..... which makes it a little more fuzzy as to which lines are for the outter patch and which ones are for the inner.... |
16:25 |
Bmagic |
in fact... I wonder if git will handle it... |
16:26 |
Dyrcona |
Probably. |
16:29 |
Dyrcona |
Well, catch you tomorrow! |
16:36 |
csharp |
GPLS has a direct conflict with the hack-a-way dates - not sure how we'll be able to reconcile it |
17:13 |
pinesol |
[evergreen|Galen Charlton] LP#1889251: make call number affix sort keys read-only - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ffc05ea> |
17:20 |
|
mmorgan left #evergreen |
17:21 |
pinesol |
[evergreen|Bill Erickson] LP1867834 Staffcat clear basket on logout - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ad66d9e> |
17:31 |
|
jvwoolf1 left #evergreen |
17:43 |
pinesol |
[evergreen|Jason Etheridge] LP1774892 stripe elements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cfabfa7> |
17:43 |
pinesol |
[evergreen|Jason Etheridge] LP1774892 stripe elements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9aa36c7> |
17:43 |
pinesol |
[evergreen|Jason Etheridge] LP1774892 stripe elements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9aada19> |
17:43 |
pinesol |
[evergreen|Jason Etheridge] LP1774892 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5b2e582> |
17:50 |
|
sandbergja joined #evergreen |
17:58 |
|
sandbergja joined #evergreen |
17:58 |
|
pastebot joined #evergreen |
18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
18:15 |
|
sandbergja joined #evergreen |
19:09 |
|
sandbergja joined #evergreen |
20:45 |
|
jlundgren joined #evergreen |
21:48 |
|
sandbergja joined #evergreen |
21:54 |
|
sandbergja joined #evergreen |
21:54 |
|
sandbergja_ joined #evergreen |
22:08 |
|
sandbergja joined #evergreen |
22:38 |
|
sandbergja joined #evergreen |
23:49 |
|
jvwoolf joined #evergreen |