summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2015-02-19 16:03:49 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2015-02-19 18:17:45 -0400
commit50596dfb95976d65346a31afd364ba5f37c3c226 (patch)
tree3ec35863ac1cd8e19a1be8b0f2917e7e28a677db
parent7f76df011528fdc6a6ec086e3c586d2117f27ffa (diff)
devblog
-rw-r--r--doc/devblog/day_257__release_day.mdwn17
1 files changed, 17 insertions, 0 deletions
diff --git a/doc/devblog/day_257__release_day.mdwn b/doc/devblog/day_257__release_day.mdwn
new file mode 100644
index 000000000..bd3057145
--- /dev/null
+++ b/doc/devblog/day_257__release_day.mdwn
@@ -0,0 +1,17 @@
+Today's release doesn't have the database branch merged of course, but it
+still has a significant amount of changes.
+
+Developed a test case for the sqlite problem, that
+reliably reproduces it, and sent it to the sqlite mailing list. It seems
+that under heavy write load, when a new connection is made to the database,
+SELECT can fail for a little while. Once one SELECT succeeds, that database
+connection becomes solid, and won't fail any more (apparently). This makes
+me think there might be some connection initialization steps that don't end
+up finishing before the SELECT goes through in this situation. I should be
+able to work around this problem by probing new connections for stability,
+and probably will have to, since it'll be years before any bug fixed sqlite
+is available everywhere.
+
+I also noticed that current git-annex incremental parallel fsck doesn't
+really parallelize well; eg the processes do duplicate work. So, the
+database branch is not really a regression in this area.