Search in #evergreen

Results

Result pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150

Results for 2013-06-04

10:59		_zerick_ joined #evergreen
11:00		tspindler joined #evergreen
11:04	Dyrcona	dbs: mens health doesn't match men's health on my catalog, either.
11:04	bshum	Well, I just tested that search on MVLC and SCLEND's catalogs and neither returned expected results
11:05	bshum	Oh, heh
11:05	dbs	Looks like your thinking that new QP might be playing a role might be a reasonable theory. I'm seeing the same difference on our 2.4 test server vs our 2.3 production server
11:06	dbs	Is SCLENDs on 2.4?
11:06	dbs	I assume MVLC is.

Results for 2013-06-03

11:51		dboyle joined #evergreen
11:53	tsbere	b_bonner: Dunno if it has anything to do with your error.....but why the subselect? The where and limit clauses should, in theory, work on the update statement directly
11:53		jdouma joined #evergreen
11:56	b_bonner	tsbere: subselect was just wanting to limit the query to the bib id's that actually have this 856 condition and the limit was just a remnant of me doing smaller scale tests.
11:57	jeff_	b_bonner: sounds like your error is related to an existing issue with one or more bibs. doing a straight-up reingest of the bib without changing a thing in the marc record would likely trigger the same error.
11:57	tsbere	b_bonner: The where clause checking position would work on the update statement itself to do the same limit, though
11:58	jeff_	b_bonner: you could add RAISE DEBUG statements (or their perl equiv) to the relevant functions in the db to surface the ID of the record(s) causing the issue.
12:16	paxed	yeah, just noticed that
12:16	phasefx	gathered at login time
12:18	b_bonner	jeff_ tsbere: sorry for delay getting back to this. I'll attempt to figure out which ID's are throwing the errors. Does this mean that these ids probably aren't indexed properly now?
12:19	jeff_	eeevil: thanks. in that case, it would be good to test the effective client_min_messages for DBI, and ensure that whatever chosen could be logged without tripping up dbd::pg.
12:19	eeevil	b_bonner: it might mean that your update isn't doing what you expect. or it might mean that you've changed settings on some index defs
12:20	eeevil	jeff_: of course, it might be fine today. I ran into that long ago
12:20	jeff_	eeevil: good to know that it might be an issue, even if it turns out not to be.
12:32	jeff_	b_bonner: but you can use full_rec to find the records to change.
12:32	* jeff_	nods
12:32	b_bonner	jeff_ eeevil: oh, sure. position wasn't that bad actually.
12:34	bshum	Testing logger: i’m
12:40	jeff_	@later tell berick i'm interested in your thoughts on bug 1187035 removing OpenILS::Utils::Editor -- you're the usual author on Editor/CStoreEditor
12:40	pinesol_green	jeff_: The operation succeeded.
12:40	jeff_	bug 1187035