diff options
author | Joey Hess <joeyh@joeyh.name> | 2015-02-19 16:03:49 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2015-02-19 18:17:45 -0400 |
commit | 50596dfb95976d65346a31afd364ba5f37c3c226 (patch) | |
tree | 3ec35863ac1cd8e19a1be8b0f2917e7e28a677db /doc/devblog | |
parent | 7f76df011528fdc6a6ec086e3c586d2117f27ffa (diff) |
devblog
Diffstat (limited to 'doc/devblog')
-rw-r--r-- | doc/devblog/day_257__release_day.mdwn | 17 |
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. |