Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/85#issuecomment-130363744
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/71#issuecomment-121134365
I'm working on getting the actual dataset used and benchmark code. The
general outline of the test though is that they loaded something like 35K
records into a Q
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/61#issuecomment-121363539
Ahh, subtle. Took me a few minutes of reading to realize that when the
optimization kicks in we store the deflate version. On a subsequent read/write
we realize
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/44#issuecomment-122094682
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-couch/pull/71
Optimize couch_ejson_compare NIF
The old nif was allocating a set of collators that were reserved and
released by each scheduler thread. This coordination and the
accompanying mutex
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/35#issuecomment-152304181
Also I think there's a bug in couch_key_tree if you specify latest=true and
one leaf happens to be a descendant of another:
https://github.com/apache
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/35#issuecomment-152303652
Successful nerd snipe: https://xkcd.com/356/
So, after reading this for a couple hours I'm pretty sure its wrong and
that its been wrong for a long time
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/35#issuecomment-152318686
Not a problem and feel free to ping. That bug I mentioned in couch_key_tree
I'm not 100% on but I figured I'd write it down somewhere at least. It may
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/35#issuecomment-152309535
I haven't got time right at the moment. Though if someone wants to just go
with that gist I wrote and the notes, the only new thing to consider is really
removing
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-epi/pull/14#issuecomment-151571240
LGTM
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-epi/pull/15#issuecomment-151571275
LGTM
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/21#issuecomment-148482620
+1. I had to reverify that we just drop any dead pids that are returned to
the pool but that checks out so this should be good to go.
---
If your
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/107#issuecomment-144771791
@rnewson @kxepal When I first saw this my first thought was to remove
_revisions entirely assuming that it was basically an accident to have included
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/107#issuecomment-144773464
@kxepal I haven't got a clue why someone might use it. But it exists so I'm
guessing someone somewhere would be angry if we removed it.
---
If your project
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/19#issuecomment-145047426
Possible.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/37#issuecomment-170142208
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/125
This looks like the right fix to me. +1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/126
Actually a better solution to this would be to match the new temp view
behavior in CouchDB single node behavior where we just create a design document
and query that.
https
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/47
I agree with @rnewson on this one. Seems like we should figure out why
we're calling JSON_DECODE too many times rather than ignoring that and just
avoiding the second invocation
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-fabric/pull/56#discussion_r0531
--- Diff: src/fabric_db_update_listener.erl ---
@@ -155,4 +162,11 @@ handle_message(done, _, _) ->
{stop,
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-fabric/pull/56
Fix fabric_db_update_listener rexi_DOWN handling
A recent change that fixed the list comprehension ended up uncovering
the fact that we don't handle rexi_DOWN errors properly. This patch
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/56
What was confusing? I did hoist mem3:shards out of the
start_update_notifiers but I didn't think that would have been confusing.
---
If your project is set up for it, you can reply
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-fabric/pull/56#discussion_r4157
--- Diff: src/fabric_db_update_listener.erl ---
@@ -155,4 +162,11 @@ handle_message(done, _, _) ->
{stop,
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/47
I believe the is_list/1 check was an attempt at seeing if the value was a
list-of-characters-string that could be passed to jiffy for decoding. Ie, it
was an earlier attempt that forgot
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/47
I think you misunderstood me about calling JSON_DECODE twice. Once was when
we parse the POST body and the second is trying to parse the value. Not that
parse_param is calling it twice
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/38#issuecomment-221650083
Or to put that another way, I'd not rely on information in a 429 response
that'll give you what rate to use because a) the rate limiting proxy may
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/38#issuecomment-221649847
I didn't see that. Also I'm not sure what a 429 response might include. I
was thinking slightly more fancy in that if you get a 429 you notify the rate
Github user davisp commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/127
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/48
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/58
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-index/pull/17
Kind of like that except you have to re-open the Db each time you call the
compact. If you don't then the recompact won't get the updated state to be able
to make progress with the view
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-index/pull/17
I think you misunderstood. You have to reopen the db in the compact
function when you go to recompact or else it won't get new states for the trees
which means that recompact won't see
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/53
That took me awhile to convince myself that fitler_reply would always be
applied to the return value. I'd suggest moving it from format_reply to just
before we return the Reply here
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-index/pull/17
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/123
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-index/pull/17
couch_util:with_db/2 uses a try/catch construct which means compact
recursing into itself isn't tail call optimized. Eventually that pid would
explode in size as the stack frames
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/37#issuecomment-182003128
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/134#issuecomment-182003098
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-mem3/pull/17#issuecomment-189335904
I agree with @rnewson that this seems awfully heavy weight. Is there a
specific case where we don't properly replace nodes in maintenance mode?
---
If your project
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-mem3/pull/17#issuecomment-189365989
Yeah, not so much. Search must just have a bug in its shard replacement
logic. If a node is in maintenance mode then the RPC worker dies and the
coordinator should
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/36#issuecomment-173657320
+1 Nice find.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/139#issuecomment-182985320
Ahhh, took me two readings of your commit message before I put the whole
thing together. I kept trying to figure out how we introduced the bug during
the merge
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/139#issuecomment-182985508
I looked at that test failure and it appears unrelated, but we might also
want to verify that as well.
---
If your project is set up for it, you can reply
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/31#issuecomment-194437399
Minor nit, but you should add a short description of the why to the commit
message. You don't need to go through the level of detail in the ticket
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/31#issuecomment-19684
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/112#issuecomment-208976522
+1 though we'll want to pay attention to reports of errors logged there. We
need this to prevent the bug from spidering but this seems like we're not
correctly
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/33#issuecomment-200961456
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/29#issuecomment-192382324
The underlying cause here is that the replicator now uses the http
connection pool for the changes feed on the source database. This was done to
handle
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/30#issuecomment-192455441
I wouldn't bother adding that to the commit message. That's just for a
historical note to explain the background of the PR. The commit message is
clear
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/30#issuecomment-192455095
+1 I'd also note that the fact its continuous in the first place looks to
be a bad merge from when we ported the clustered version of the replicator
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/29#issuecomment-192500158
Also +1 that i forgot.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/34#issuecomment-204155467
Not a bad idea. I'd not try and add it to the current replicator though as
there are way too many sharp corners with the HTTP stuff for us to trip up
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/161#issuecomment-209554817
I should've made the point that ionice doesn't work if you're using noop io
scheduling.
---
If your project is set up for it, you can reply to this email
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/161#issuecomment-209554642
@kxepal We actually stole the truncate-to-zero approach from a talk at one
of the devops conferences some years ago. Its purely based on the observation
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/158#issuecomment-209546028
This looks odd to me. So I have this right, an example:
Path1 == <<"shards/-/username/dbname.234234234">>
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/43#issuecomment-214429057
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/35#issuecomment-213107502
Check out #47 for I think the fix to this.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-couch/pull/167
Fix couch_key_tree:get_key_leafs/2
This is a fix for a long standing bug when retrieving all leaf keys for
a given set of keys. Before this patch we would incorrectly return some
keys
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-couch/pull/166
Export couch_key_tree:merge/2
This is needed by fabric_doc_open_revs to fix COUCHDB-2863.
COUCHDB-2863
You can merge this pull request into a Git repository by running:
$ git
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-fabric/pull/47
Fix fabric_doc_open_revs
When a user specified multiple revisions on a single branch to
fabric_doc_open_revs it would throw a function clause exception in
lists:zipwith/3. This was due
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/47#issuecomment-213107256
This requires these two PRs to be merged:
https://github.com/apache/couchdb-couch/pull/166
https://github.com/apache/couchdb-couch/pull/167
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/168#issuecomment-215467938
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-fabric/pull/47#discussion_r60661526
--- Diff: src/fabric_doc_open_revs.erl ---
@@ -56,266 +57,391 @@ go(DbName, Id, Revs, Options) ->
rexi_monitor:stop(RexiMon)
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/161#issuecomment-215475012
Awesome work. +1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-fabric/pull/47#discussion_r60661239
--- Diff: src/fabric_doc_open_revs.erl ---
@@ -56,266 +57,391 @@ go(DbName, Id, Revs, Options) ->
rexi_monitor:stop(RexiMon)
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-fabric/pull/47#discussion_r60668584
--- Diff: src/fabric_doc_open_revs.erl ---
@@ -56,266 +57,390 @@ go(DbName, Id, Revs, Options) ->
rexi_monitor:stop(RexiMon)
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-index/pull/16#discussion_r64073496
--- Diff: src/couch_index.erl ---
@@ -407,3 +394,160 @@ assert_signature_match(Mod, OldIdxState, NewIdxState)
->
{Sig, Sig} -&
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/28#issuecomment-220133188
+1 to making it priv/**/*.d
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/28#issuecomment-220133264
Erp! Formatting
priv/**/*.d
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-index/pull/16#discussion_r63764248
--- Diff: src/couch_index.erl ---
@@ -407,3 +394,160 @@ assert_signature_match(Mod, OldIdxState, NewIdxState)
->
{Sig, Sig} -&
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-index/pull/16#discussion_r63764967
--- Diff: src/couch_index.erl ---
@@ -407,3 +394,160 @@ assert_signature_match(Mod, OldIdxState, NewIdxState)
->
{Sig, Sig} -&
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-index/pull/16#discussion_r63764684
--- Diff: src/couch_index.erl ---
@@ -407,3 +394,160 @@ assert_signature_match(Mod, OldIdxState, NewIdxState)
->
{Sig, Sig} -&
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-index/pull/16#issuecomment-220387961
For background on this, "recompaction" is just an internal name for the
step during view compaction when we spawn an index updater to top off a
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-index/pull/16#issuecomment-221310546
@iilyak +1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-fabric/pull/47#discussion_r63547840
--- Diff: src/fabric_doc_open_revs.erl ---
@@ -56,266 +57,390 @@ go(DbName, Id, Revs, Options) ->
rexi_monitor:stop(RexiMon)
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/47#issuecomment-219763847
Updated as per @iilyak's feedback.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/173#issuecomment-219841242
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/115#issuecomment-216667074
Right, I'm just saying there's no reason to prefer it over sending a
message to self.
---
If your project is set up for it, you can reply to this email and have
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-index/pull/14#issuecomment-216579991
This turned out to be an awfully big change. In hindsight I don't think
we're going to get much benefit out of reopening the database (I made that
assumption
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/115#issuecomment-216585377
+1 I wouldn't bother with gen_server:cast/2 as its nothing more than self()
! {'$gen_cast', Msg} which is just adding unnecessary code.
---
If your project
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-chttpd/pull/114#issuecomment-216596670
Couple things jump out at me here. First, this appears to be opening up a
bit of a DOS vector in that the max body size is not hard coded to 4GiB without
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/162#issuecomment-210532037
Good point @rnewson. I'd go with the 400 approach then.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/162#discussion_r59885221
--- Diff: src/couch_changes.erl ---
@@ -336,6 +343,16 @@ get_doc_ids(_) ->
throw({bad_request, no_doc_ids_provi
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/162#discussion_r59884495
--- Diff: src/couch_changes.erl ---
@@ -349,6 +366,18 @@ check_docids(_) ->
throw({bad_request, Msg}).
+check_selector(Selec
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/162#issuecomment-210489852
Except for the various tweaks to error messaging, +1 to the feature. Sure
did come out a lot simpler than I was expecting.
---
If your project is set up
Github user davisp commented on the pull request:
https://github.com/apache/couchdb/pull/402#issuecomment-210619148
I like build. Nothing else i can think of isnt already used between make
and Erlang.
> On Apr 15, 2016, at 1:33 PM, Jan Lehnardt <notificati...@gith
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/36#issuecomment-211477644
LGTM, +1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-fabric/pull/45#issuecomment-212117786
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/160#issuecomment-212117735
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/35#issuecomment-212118248
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/161#discussion_r60137566
--- Diff: src/couch_file.erl ---
@@ -252,14 +252,23 @@ deleted_filename_suffix() ->
[Y, Mon, D, H, Min, S, couch_uuids:ran
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/pull/161#issuecomment-211596768
So thinking through this I think we may be conflating two different
features that while similar are serving different purposes.
Specifically, there's one
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch-replicator/pull/38#issuecomment-221400655
Two major thoughts occur to me reading this. First, for responding to 429
responses it seems like something a bit more reactive would be more useful
Github user davisp commented on the issue:
https://github.com/apache/couchdb/pull/433
Your diff did not render so hot
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/190
Thanks for the explanation of your thoughts there as that shows we're
definitely thinking about this differently. For reference, here's my
description of what I think should be going
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/190
I think setting hard limit to a huge number is close enough to disabling it
given that there are maximum numbers of os processes and the like.
---
If your project is set up for it, you can
Github user davisp commented on the issue:
https://github.com/apache/couchdb-config/pull/10
@iilyak I changed the function to subscribe and added a test to show that
gen_event_EXIT is handled properly. I'll wait for another +1 on that new test
before merging.
---
If your project
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/190#discussion_r74157712
--- Diff: src/couch_proc_manager.erl ---
@@ -436,9 +436,8 @@ assign_proc(#client{}=Client,
#proc_int{client=undefined}=Proc) ->
assign_p
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/190
I'm pretty sure this is wrong. remove_proc is only called when a proc is
exiting either due to an error or when it times out after idle. So your change
still delays allocating waiters until
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/185
I like the idea here but I think we need to rethink the implementation a
bit. First, the timing numbers reported are in microseconds so I'm not super
convinced on them. What size of file
1 - 100 of 285 matches
Mail list logo
