tomwardilllanding the last of the sass branches07:18
tomwardillwgrant: if you get a mo for a hopefully simple DB review: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/38412907:19
wgranttomwardill: Reviewed.07:36
tomwardillblergh, actual test failures for master08:04
tomwardilllooking now08:04
wgrantHm, I thought I'd cleaned up the buildbot failures earlier08:12
wgrantOh a landing broke it, nvm08:12
tomwardillyeah, at least one of them is reproducible locally08:12
wgrant... slightly odd landing to break it, though.08:13
tomwardillJS failure somehow, so not entirely weird08:13
tomwardillalthough it does mean I have to work out how to debug these tests08:14
wgrantYou can usually run them in your normal browser just by opening the listed HTML file08:15
tomwardillyeah, I've got that08:15
tomwardill... picked a pickled pepper?08:18
tomwardillwell, found 2 other bugs, but not fixed that one yet08:54
tomwardillfound it08:59
tomwardillhttps://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/384954 fix css imports in tests09:07
cjwatsonMaking decent progress with the OCI registry upload status UI, but having to fix a few bits of model along the way first09:07
tomwardillslightly surprised that change only broke two tests, but there we go.09:08
tomwardillcjwatson: just pushed a change to flip the order of 'base' and 'components' (and fix the comment), as in the old method the components css was appended to the list09:11
tomwardillso base was never actually the last import, despite what the comment said09:11
cjwatsonI wondered about that.  Also fine.09:11
cjwatsonOh also09:12
tomwardillthanks, landing09:12
cjwatsonCan you fix the node-sass version in that comment?09:12
tomwardill.. not landing09:12
cjwatsonThanks, go ahead09:12
* tomwardill -> coffee and then DB patch09:13
tomwardill\\ΓΈ/ build success10:09
cjwatsonWill probably be worth having a manual look over qastaging once it updates10:11
cjwatsonJust to make sure there are no obvious oddities from the uplift10:11
tomwardillwgrant: the ocifile date_last_used shouldn't contend too much, I can't see us building enough oci images often enough to hit lock contention on that table10:12
tomwardilland the garbage job collects every 7 days, so it shouldn't bloat with 'dead' images either10:12
tomwardillcjwatson: yeah, I'll be doing that10:12
wgrantOh, that's not what I mean by bloat.10:12
wgrantI mean PostgreSQL relation tuple bloat.10:12
* tomwardill does not know what that means, I'm afraid10:13
wgrantOh right, Mr. MongoDB Background :)10:14
tomwardillit's hard to have bloat when you have no data10:14
wgranttomwardill: PostgreSQL's MVCC implementation means that a row's data on disk is actually immutable. The physical manifestations of a row are often referred to as "tuples", and contain the actual row data, plus metadata like the transaction IDs where the tuple was created and deleted. An update to a row actually marks the old tuple as deleted and creates a new one, and updates any indexes to point at10:17
wgrantboth. VACUUM is the process that runs (usually automatically) to find old tuples that aren't visible to any current transactions, and properly deletes them.10:17
wgrantThis works nicely, except when you have long-running transactions like, say, a backup. Since the backup runs in a transaction that references an old snapshot of the DB, tuples that were deleted during the backup cannot be properly deleted until the backup completes.10:18
wgrantThis doesn't just cause the table to grow in size - it can also slow things down significantly, as the index will reference all the tuples and queries will have to fetch them all to work out which one is alive.10:19
wgrantThis has mostly been a problem on tables like Builder and BuildQueue, where existing rows get updated frequently and automatically by buildd-manager.10:19
tomwardillaah, right10:20
wgrantIt is also seen occasionally when an appserver hangs in the middle of a transaction for a couple of days. The whole app can start to slow down due to all the dead tuples lying around.10:20
tomwardillthat makes sense10:22
tomwardillI don't think we're going to be updating that table with that level of frequency10:22
tomwardill(pending an OCI based team decided they need minutely rebuilds or something)10:23
wgrantBut what if there are a million users building things based on ubuntu:18.04!10:25
wgrant(but yes, unlikely to be a problem at the start, and we can always only update it if it's at least an hour old and SKIP LOCKED, or something like that, down the line if we need to)10:25
wgrantBut something to think about in future.10:25
tomwardillyes, and not something I knew to consider, so thanks for the explanations :)10:25
cjwatsonhttps://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/384952 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/384957 are a couple of fixes to various bits of the OCI upload arrangements.  They're independent, but I'd like to get at least one of them reviewed please so that I can linearise work based on both of them10:39
tomwardilllooking now10:40
tomwardillqastaging is showing a 500 error again10:53
cjwatsonRight, but this is a normal one with a proper error page10:58
cjwatsonqastaging doesn't update itself in a nodowntime kind of way, so it routinely does this in the middle of updates10:59
cjwatsonHowever - atemoya.canonical.com::qastaging-logs/qastaging-update.log doesn't show it as being in the middle of an update right now10:59
cjwatsonOh, hm, the sudoers fix apparently didn't quite take10:59
cjwatson-> #launchpad-ops11:00

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!