| Time |
Nick |
Message |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:24 |
|
collum joined #evergreen |
| 07:24 |
|
rjackson_isl_hom joined #evergreen |
| 08:27 |
|
Dyrcona joined #evergreen |
| 08:30 |
|
awitter joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:38 |
|
mantis joined #evergreen |
| 08:45 |
Dyrcona |
It bugs me that a pgtap test can succeed, but when running one of the inserts outside of a transaction blows up. I believe that is caused by a deferred trigger, which ain't so deferred if there isn't a transaction. |
| 09:02 |
Dyrcona |
All right. All pgtap tests now succeed on Pg 10 and Pg 11 with XPath fixes. |
| 09:04 |
Dyrcona |
Things get more interesting at Pg 12 and beyond. |
| 09:11 |
|
rfrasur joined #evergreen |
| 09:19 |
Dyrcona |
Aight. The unaccent business is a pain. |
| 09:21 |
Dyrcona |
The behavior changes multiple times from Pg 12 to Pg 14 for unaccenting characters. |
| 09:32 |
Dyrcona |
Well, twice. That's multiple, yeah? |
| 09:35 |
Dyrcona |
So, you're best when upgrade to Pg 12 or to Pg 14 is a dump and reload. Same if you upgrade the O/S from Ubuntu 18.04 to Ubuntu 20.04, just throwing that out there. |
| 09:35 |
Dyrcona |
s/you're/your/ |
| 09:35 |
Dyrcona |
@blame My fingers |
| 09:35 |
pinesol |
Dyrcona: Dyrcona's fingers broke Evergreen. |
| 09:36 |
Dyrcona |
Ha! They probably have more than once. |
| 09:37 |
Dyrcona |
I don't think stuck to the wall, and if it did, it probably should not have. :) |
| 09:38 |
Dyrcona |
Why can't I type a complete sentence this morning without omitting a word? |
| 09:38 |
Dyrcona |
@blame Friday |
| 09:38 |
pinesol |
Dyrcona: Friday must eat cottage cheese! |
| 09:38 |
Dyrcona |
Aight... Two more tests that fail on Pg 12+.... |
| 09:41 |
Dyrcona |
Looks like I fix them both if I fix one. |
| 10:05 |
Dyrcona |
Y'know, it would be handy to add an option to eg_db_config to create the pgtap extension. |
| 10:06 |
Dyrcona |
But, maybe that's just cause I reload the schema on multiple databases multiple times a day. |
| 10:12 |
Bmagic |
Dyrcona: without any of this code your writing, if someone were to upgrade the database server to 20.04... well, I suppose a dump and restore would probably be the best course of action even if it weren't for these xpath things |
| 10:16 |
Dyrcona |
Bmagic: Pg 10 on 20.04 will work just fine so long as you dump and reload or recreate a bunch of indexes: https://elephanttamer.net/?p=61#brokenindexes |
| 10:16 |
Dyrcona |
What I'm going is irrelevant to the O/S, just Pg versions. |
| 10:23 |
|
_collum joined #evergreen |
| 10:24 |
|
collum_ joined #evergreen |
| 10:25 |
|
collum__ joined #evergreen |
| 10:36 |
JBoyer |
BAH. I just noticed we still have Freenode listed as our IRC network in the install instructions on evergreen-ils.org :( |
| 10:36 |
JBoyer |
For both osrf and evergreen. |
| 10:46 |
Dyrcona |
Keep backups, kids, even when you think you don't need them. |
| 10:59 |
Dyrcona |
JBoyer++ |
| 10:59 |
Dyrcona |
git++ |
| 11:00 |
Dyrcona |
Having out of date repos scattered around is sometimes beneficial. |
| 11:00 |
Dyrcona |
I managed to find a branch that hadn't been updated since Monday, but JBoyer found one from Wednesday. |
| 11:14 |
Dyrcona |
JBoyer++ # Double the thanks for jumping through fomat-patch and other hoops! |
| 11:33 |
jeff |
fermat-patch? :-) |
| 11:36 |
Dyrcona |
Fermat's last patch? |
| 11:43 |
jeff |
less of a patch, and more of a wishlist bug with a mention of a working branch that the bug is too "narrow to contain". |
| 11:43 |
jeff |
(yeah, the analogy falls apart a bit.) |
| 11:43 |
Dyrcona |
Heh |
| 11:52 |
Dyrcona |
So close, yet so far.... |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:33 |
JBoyer |
Fermat's Last Patch was a proof that devs^n + wishlists^n = features^n is not true when n (number of users) is larger than a certain value. Sadly it didn't fit in max_stanza_size. |
| 12:35 |
mmorgan |
JBoyer++ |
| 12:35 |
berick |
heh |
| 12:35 |
jeff |
JBoyer++ for finding a more appropriate analogue for Fermat's narrow margin. :-) |
| 12:35 |
|
collum joined #evergreen |
| 12:36 |
JBoyer |
Always creeping closer to Zeno's pair of ducks. |
| 12:54 |
Dyrcona |
:) |
| 12:55 |
Dyrcona |
Quack! |
| 13:01 |
Dyrcona |
! is the one good thing from C shell that was imported to Bash. |
| 13:02 |
|
collum joined #evergreen |
| 13:16 |
Dyrcona |
Heisenberg is definitely a PostgreSQL developer. |
| 13:25 |
mmorgan |
Dyrcona: Are you certain about that? ;-) |
| 13:29 |
Dyrcona |
mmorgan++ |
| 13:34 |
Dyrcona |
I think I've uncovered quantum entanglement in Pg 10. |
| 13:36 |
Dyrcona |
I've loaded the test data for Pg/live_t/lp1145213_test_func​_asset.merge_record_assets.pg on both Pg 10 and Pg 12. |
| 13:37 |
Dyrcona |
It then run a modified version of asset.merge_record_assets on the records as is done in the test. |
| 13:37 |
Dyrcona |
On Pg10 I get 4 moved objects: 1 metarecord and 3 call numbers. On Pg 12 I get 3 moved objects, the call numbers. |
| 13:39 |
Dyrcona |
Aight, so I think the metarecord isn't created on Pg 12, so I reload the databases, and reload the test data. I check the metabib.metarecord table with the same query used by asset.merge_record_assets. There's no metarecord entry with 60001 as the master record in either database. |
| 13:41 |
Dyrcona |
Instead, the two inserted records (60000 and 60001) are in the source maps of two other metarecords, 17 and 35, respectively. |
| 13:42 |
Dyrcona |
Somehow, between starting to run the merge_record_assets function and it getting to the master record check, the metabib.metarecord entry is created, but I don't see any updates or anything else that would do that. |
| 13:43 |
Dyrcona |
The function basically just looks for asset.uris, doesn't find any in this case, then looks for the metarecord which shouldn't be there, but is on Pg 10. |
| 13:47 |
Dyrcona |
The future seems to be influencing the past. I didn't know we'd reached that level of quantum computing. |
| 13:50 |
csharp_ |
still digging into my mystery issue that causes open-ils.actor to die multiple times per day... |
| 13:50 |
csharp_ |
"Received <error> message with type cancel and code 503" |
| 13:51 |
Dyrcona |
Um.... I add 1 additional RAISE NOTICE and the behavior changes to be what I'd expect..... |
| 13:51 |
csharp_ |
I'm currently working under the assumption that this message is not the culprit but is the first message after the culprit - could be wrong though |
| 13:52 |
Dyrcona |
Both Pg versions report 3 move call numbers and no metarecord shenanigans. |
| 13:52 |
Dyrcona |
csharp_: I've given up on assumptions... |
| 13:56 |
jeffdavis |
csharp_: is there a Launchpad bug for that? Not to add to your todo list, just wondering if relevant info is already gathered together somewhere. |
| 13:57 |
csharp_ |
let me look |
| 14:03 |
Dyrcona |
My case feels like I'm overlooking something obvious, but I think I'm just living in non-Euclidean universe. |
| 14:11 |
jeff |
Escherian geometry |
| 14:12 |
Dyrcona |
Lovecraftian |
| 14:24 |
Dyrcona |
Turns out Heisenberg in an Evergreen programmer. :) |
| 14:27 |
Dyrcona |
So, if the quality of two or more bibs is the same, it's undetermined which one becomes the master record. It depends on the order that they come out of the database, which is not always id order. |
| 14:28 |
Dyrcona |
We've been lucky up until now that this test has passed. |
| 14:29 |
Dyrcona |
I'm going to add id ascending on the order by so that that best bib with the lowest id number is picked. It's already excluding deleted bibs. |
| 14:52 |
JBoyer |
Dyrcona++ # Modern Pg support progress |
| 14:54 |
|
rjackson_isl_hom joined #evergreen |
| 14:59 |
Dyrcona |
"All test successful" at least on Pg 10 and Pg 14 for pgtap. I'll get to the Perl tests after I do something else, but the Perl tests were all passing but 1 before and I fixed that one. Hopefully, noting I did causes any new issues. |
| 15:09 |
Bmagic |
Dyrcona++ |
| 15:15 |
mmorgan |
Dyrcona++ |
| 15:17 |
Dyrcona |
Thank you, thank you. I've been wanting to move to more recent PostgreSQL for a while. |
| 15:19 |
Dyrcona |
So Perl tests pass on Pg 10 and Pg 14 on my local VM. I'll run them again on a different vm later. |
| 15:19 |
Dyrcona |
I'm going to do Pg 10 through Pg 14 on a VM that has access to that big database server. |
| 15:20 |
Dyrcona |
I "accidentally" installed Pg 14 along side Pg 10 on this local VM and decided to keep it for testing. |
| 15:45 |
Dyrcona |
This is bad. The Perl live tests succeeded on my local VM but they failed on the remote vm.... /sigh |
| 15:48 |
Dyrcona |
Hrm. I wonder if the IDL was up to date? |
| 15:52 |
Dyrcona |
IDK. It's the same versions of everything, and the Perl live tests are failing..... |
| 15:54 |
Dyrcona |
So, we'll make clean and try again. |
| 15:59 |
Dyrcona |
Aight, make sure to reload the database. |
| 15:59 |
Dyrcona |
Oh! I don't think I set the admin password correctly. |
| 16:04 |
Dyrcona |
oof. I have to reload all of the databases... |
| 16:22 |
Bmagic |
what fun |
| 16:26 |
Dyrcona |
I'm pretty sure that forgetting to set the admin-use and admin-pass was my problem, but I'll probably wait until Monday the 29th before testing it on this vm. |
| 16:26 |
Dyrcona |
It worked on my other vm. |
| 16:26 |
Bmagic |
othre_vm++ |
| 16:26 |
Bmagic |
other_vm++ # also |
| 16:26 |
Dyrcona |
Dunno if I'll clean up the branch this week or if I'll wait. |
| 16:26 |
Dyrcona |
vm++ |
| 16:26 |
Bmagic |
Nothing like the "later" |
| 16:31 |
Dyrcona |
Heh. |
| 16:32 |
Dyrcona |
Well, I'm officially done for the day, so signing out. |
| 16:37 |
JBoyer |
Dyrcona++ |
| 17:00 |
|
mmorgan left #evergreen |
| 17:31 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
