This is an automated email from the ASF dual-hosted git repository.
davisp pushed a change to branch main
in repository https://gitbox.apache.org/repos/asf/couchdb-recon.git.
at 1ddebb6 Merge pull request #74 from gomoripeti/trace_fmt_extra_msg
No new revisions were added by this update.
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-snappy/pull/9#discussion_r225681578
--- Diff: c_src/snappy_nif.cc ---
@@ -100,6 +94,21 @@ SnappyNifSink::getBin()
}
+void
+SnappyNifSink::EnsureSize(size_t
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-snappy/pull/9
Fix memory bug in SnappyNifSink::Append
Previously `SnappyNifSink` assumed that `GetAppendBuffer` was always
called before `Append`. This turned out to be an invalid assumption
Github user davisp commented on the issue:
https://github.com/apache/couchdb-snappy/pull/7
Oh, its a permissions thing. Ignore my rambling.
---
Github user davisp commented on the issue:
https://github.com/apache/couchdb-snappy/pull/7
Oh, except it looks like we have to make them pass for the merge button?
---
Github user davisp commented on the issue:
https://github.com/apache/couchdb-snappy/pull/7
Tested locally and it works so will ignore it.
---
Github user davisp commented on the issue:
https://github.com/apache/couchdb-snappy/pull/7
+1
---
Github user davisp commented on the issue:
https://github.com/apache/couchdb-snappy/pull/7
Is it normal for all of the tests to fail?
---
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-ets-lru/pull/5
Fix flaky tests
The bad options test had a race condition between the process exit and
the unregistering of the name. If the unregister didn't happen quickly
enough then the next bad
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-config/pull/15
Fix eunit tests
Minor tweaks to the tests so that they stop all applications that needed
starting. It also removes an extraneous couch_stats dependency.
You can merge this pull request
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/241
And I hesitate to store the total number of rows because there'd then be
upgrade things to worry about and generally speaking this will just sort itself
out while still giving an approximate
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/241
Updated to use define's for batch sizes and fixed the changes/doc count
mixup.
For the {merge_start, forward}, thats only there for completeness. It felt
a bit weird to not include
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/241
Also I need to change my use of DocCount to be TotalChanges. I noticed
while testing the optimizations I tried that its currently not correct during
compaction retries.
---
If your project
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/241#discussion_r109026748
--- Diff: src/couch_db_updater.erl ---
@@ -1323,12 +1326,82 @@ bind_id_tree(Db, Fd, State) ->
Db#db{id_tree=IdBt
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-couch/pull/241
Improve compaction task status updates
Previous the emsort related operations did not update the compaction
task status. For large databases this leads to some very long waits
while
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-log/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 a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/239#discussion_r106261898
--- Diff: src/couch_lru.erl ---
@@ -16,48 +16,57 @@
-include_lib("couch/include/couch_db.hrl").
new() ->
-{g
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
I would do it in the Makefile before we run the test suite, not as part of
the code bits.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
@nickva @eiri Aha! Different conversation!
Removing the max_dbs_open hard limit and swapping to a soft limit has been
suggested a few times and then we'd end up relying on the nfile
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r105942223
--- Diff: src/couch_mrview_index.erl ---
@@ -230,20 +230,23 @@ update_local_purge_doc(Db, State) ->
verify_index_exists(Opti
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
@eiri Am I mistaken that not calling db_closed was the issue? I'm not
seeing the subtlety of your clarification.
---
If your project is set up for it, you can reply to this email and have
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
@nickva I don't think its worth having two settings when we're looking at
minutes as anything under load ends up reverting to the current behavior
(assuming we don't introduce bugs
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
@eiri The subtlety here is that anything marked as a sys_db is outside the
LRU and never gets closed (ie, they exist outside the max_dbs_open setting).
The change here is to close anything
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
I'm not seeing the users thing as being an issue. Unless you mean its being
actively read when it closes in which case our is_idle check is wrong?
---
If your project is set up for it, you
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
For GC, that may be enough. Granted hibernate is more aggressive and just
calling erlang:garbage_collect() can run into issues that hibernate fixes (ie,
lots of ram and not much activity
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r105929893
--- Diff: src/couch_mrview_index.erl ---
@@ -204,3 +208,56 @@ index_file_exists(State) ->
} = State,
IndexFN
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r105926830
--- Diff: test/couch_mrview_purge_docs_tests.erl ---
@@ -0,0 +1,126 @@
+% Licensed under the Apache License, Version 2.0 (the "License&q
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r105926127
--- Diff: src/couch_mrview_index.erl ---
@@ -204,3 +208,56 @@ index_file_exists(State) ->
} = State,
IndexFN
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r105926680
--- Diff: src/couch_mrview_util.erl ---
@@ -39,6 +41,26 @@
-include_lib("couch_mrview/include/couch_mrvie
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r105926330
--- Diff: src/couch_mrview_index.erl ---
@@ -204,3 +208,56 @@ index_file_exists(State) ->
} = State,
IndexFN
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/236#discussion_r105919410
--- Diff: src/couch_db_updater.erl ---
@@ -1454,3 +1468,44 @@ default_security_object(_DbName) ->
"
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
@eiri @nickva Ah! Though slightly different. The bug is that we weren't
calling db_closed to decrement the number of open databases. Nothing to do with
system dbs being in ets. If you read
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/236#discussion_r105918204
--- Diff: src/couch_db_updater.erl ---
@@ -1454,3 +1468,28 @@ default_security_object(_DbName) ->
"
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/236#discussion_r105803925
--- Diff: src/couch_db_updater.erl ---
@@ -1454,3 +1468,28 @@ default_security_object(_DbName) ->
"
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/236#discussion_r105803958
--- Diff: src/couch_server.erl ---
@@ -173,6 +174,15 @@ hash_admin_passwords(Persist) ->
config:set("admins"
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/236#discussion_r105803775
--- Diff: src/couch_db_updater.erl ---
@@ -1454,3 +1468,28 @@ default_security_object(_DbName) ->
"
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
I'd probably avoid adding load to the config changes listener system as
that already has a habit of getting backed up.
On Mon, Mar 13, 2017 at 6:09 PM Benjamin Bastian <notific
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/236
I like this change for the most part though I also think @sagelywizard is
spot on in wondering how much extra load this will add to couch_server. However
I don't have any better ideas on how
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-replicator/pull/59
+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/pull/231
+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 a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/229#discussion_r103794067
--- Diff: src/couch_query_servers.erl ---
@@ -169,6 +178,19 @@ sum_values(Value, Acc) when is_number(Value),
is_list(Acc) ->
sum_arrays(
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/229#discussion_r103793859
--- Diff: src/couch_query_servers.erl ---
@@ -142,25 +142,34 @@ os_rereduce(Lang, OsRedSrcs, KVs) ->
builtin_reduce(_Re, [], _KVs,
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/229
Reduce functions are complicated so that makes sense. :D
Unfortunately there's not a whole lot we can do without inventing a
builtin-reduce specific error API/protocol which strikes me
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/229#discussion_r103793405
--- Diff: src/couch_query_servers.erl ---
@@ -142,25 +142,34 @@ os_rereduce(Lang, OsRedSrcs, KVs) ->
builtin_reduce(_Re, [], _KVs,
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r103232925
--- Diff: src/couch_mrview_index.erl ---
@@ -204,3 +208,53 @@ index_file_exists(State) ->
} = State,
IndexFN
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r10327
--- Diff: src/couch_mrview_util.erl ---
@@ -38,6 +39,26 @@
-include_lib("couch/include/couch_db.hrl").
-include_lib(&qu
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r103233058
--- Diff: src/couch_mrview_util.erl ---
@@ -38,6 +39,26 @@
-include_lib("couch/include/couch_db.hrl").
-include_lib(&qu
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r103232522
--- Diff: src/couch_mrview_cleanup.erl ---
@@ -41,7 +41,20 @@ run(Db) ->
lists:foreach(fun(FN) ->
couch_log
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/67#discussion_r103233260
--- Diff: src/couch_mrview_index.erl ---
@@ -204,3 +208,53 @@ index_file_exists(State) ->
} = State,
IndexFN
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/67
LGTM though we can't merge this until after PSE stuff lands of course.
I just have a few minor style tweaks to note but otherwise this looks
pretty good all around.
---
If your
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/229
My bad, I missed the fact that we were talking about removing the top level
value. I don't think we should do that in this case because of what I described
earlier. These are just alternative
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/229
That was a really confusing description in hindsight...
Consider it this way: what you're changing could easily be written as a
custom reduce function in JavaScript. The only
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch/pull/229#discussion_r102814914
--- Diff: src/couch_query_servers.erl ---
@@ -169,8 +177,20 @@ sum_values(Value, Acc) when is_number(Value),
is_list(Acc) ->
sum_arrays(
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-couch/pull/228
Couchdb 3298 improve couch btree chunkify
This PR adds two slight tweaks to the couch_btree:chunkify/1 function.
First, rather than create a larger number of evenly sized chunks
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/65#discussion_r100305494
--- Diff: src/couch_mrview_index.erl ---
@@ -23,84 +23,77 @@
-include_lib("couch_mrview/include/couch_mrview.hrl").
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/65
Also, +1 after the slight tweak.
---
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-couch-mrview/pull/65
I'll second re-using `get(update_options, State)` since those are prime
suspects for being typoed if we ever change them.
Six-year-ago-me re-apologizes for couch_mrview
Github user davisp commented on a diff in the pull request:
https://github.com/apache/couchdb-couch-mrview/pull/65#discussion_r99875440
--- Diff: src/couch_mrview_index.erl ---
@@ -23,84 +23,80 @@
-include_lib("couch_mrview/include/couch_mrview.hrl").
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/223
Awesome find. I've definitely been perplexed by the I/O changes since
starting to deploy Couch 2.0 code. This definitely seems to explain both the io
differences and the increase in memory
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/84
That record shouldn't be an issue during hot code upgrades either since as
@nickva points out its internal to the module.
---
If your project is set up for it, you can reply to this email
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/222
+1
Also a note that this was caught by inspection and remembering we've seen
weirdness when a hdd runs out of space. A possible cause would be getting
enospc errors from writes
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/83
I don't agree that upgrading a cluster without downtime is something only
Cloudant cares about. Granted we don't really have a process around this but I
think we'll want to figure something
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/83
You decided to ignore the upgrade issues?
---
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-fabric/pull/83
+1 to the change but we should add a test for it. Granted there's not much
in that module for tests right now.
---
If your project is set up for it, you can reply to this email and have your
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/83
+1 to the change but we should add a test for it.
---
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-fabric/pull/83
We either need to make this two commits/PRs or figure out a way to feature
flag it so that users running rolling reboots don't have a bunch of 500s during
the upgrade.
---
If your project
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/219
A note on the earlier conversation, the point of the original 'EXIT'
handling code was so that couch_file could outlive its parent. But that's not
possible because even if we trap exits
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/219
+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/pull/218
The name, content type, and body (via md5) determine the revision. If you
specify a different body then you should expect a different revision id, yes.
---
If your project is set up
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/218
For color, the reason we ran into this now is because in a cluster we rely
on the generated revisions to be exactly the same. We happened to have a user
that was basically running "D
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-couch/pull/218
Make revision generation deterministic
This removes the influence of the attachment disk information when
generating revisions when a document is being recreated (ie, it existed
once
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/217
Oh heh, the travis CI check doesn't even include this commit when it runs
the tests so I'm just gonna go ahead and ignore that.
---
If your project is set up for it, you can reply
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/217
And yeah, the couchdb_mrview_tests module failed with a bad response code
which didn't happen locally (those are actually in src/couch/test which I ran).
Most odd.
---
If your project is set
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/217
Here's a micro benchmark that shows a significant speedup for the new
version. Between 1,000% and 6,000% depending on whether it actually has to
remove the suffix.
```erlang
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/217
Oh whoops. I forgot to run the full suite. Just ran couch tests. Will check
the full run and also add a benchmark as well.
---
If your project is set up for it, you can reply to this email
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-couch/pull/217
Remove use of filename:rootname/1
It turns out that filename:rootname/1 is fairly expensive. Given that we
call it millions of times when doing database name validation it adds up
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/216
This one:
https://github.com/apache/couchdb-couch/commit/62dafe81e13d7f8e27e95057e65f76d534aa2313
And make sure the rest of that commit is applied as well.
---
If your project is set
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/216
+1. But add a reference to Randall's commit that somehow got reverted.
---
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 issue:
https://github.com/apache/couchdb-fabric/pull/78
+1 for posterity.
---
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
Github user davisp commented on the issue:
https://github.com/apache/couchdb-fabric/pull/77
+1 for this one
---
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/pull/205
+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/76
Yes, but make this two PRs so that you can merge them intelligently. Took
me a few minutes to realize that your PR description is saying this goes into
two different releases. People are going
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-fabric/pull/74
Track open_shard timeouts with a counter
The open_shard RPC endpoint is used to grab security docs. There are
fairly aggressive timeouts on these requests so that when a node is too
Github user davisp commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/114
Correct.
---
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-chttpd/pull/114
I don't follow what you mean. All requests go to the socket if you go far
enough.
---
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 the pull request:
https://github.com/apache/couchdb-couch/commit/39357ed8102e9ea3367a012ed17c9a0940cdc38f#commitcomment-19457218
Also, this compare view link should maintain current code so anyone can see
progress. I'm currently chasing down what I
Github user davisp commented on the pull request:
https://github.com/apache/couchdb-couch/commit/39357ed8102e9ea3367a012ed17c9a0940cdc38f#commitcomment-19457203
GitHub is being weird. I wasn't seeing your comment about the bug until I
added more commits. And now I can't see your old
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/58
@jaydoane The ~r is a custom control character I added to couch_log to
simplify formatting error terms:
https://github.com/apache/couchdb-couch-log/commit
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/58
I'd be fine with just adding unit tests. I don't know how we'd test
behavior very well on this with an integration test as the bad cases are all
when views get huge, which isn't super
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/58
Already see a bug, The $gen_cast message needs to use a different variable
name which it passes to recompact_loop so that we don't get a bad match.
---
If your project is set up
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch-mrview/pull/58
That's the general idea, though there was a bit I wanted to add using the
update/3 so that we know if the updater is making progress between failures. I
typed up a quick thing
Github user davisp commented on the issue:
https://github.com/apache/couchdb-documentation/pull/78
+1 to merge assuming the travis-ci checks pass.
---
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 a diff in the pull request:
https://github.com/apache/couchdb-documentation/pull/78#discussion_r82298531
--- Diff: src/config/couchdb.rst ---
@@ -105,15 +105,21 @@ Base CouchDB Options
[couchdb]
max_dbs_open = 100
Github user davisp commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/143
+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/pull/201
+1 but we'll want to document the new behavior somewhere. Also, you don't
need the Jira: in front of your COUCHDB-3174 in the commit message.
---
If your project is set up for it, you can
GitHub user davisp opened a pull request:
https://github.com/apache/couchdb-fabric/pull/72
Send a message when filtering a changes row
We managed to miss this change during the great merge as it was a
confusing mess in the cloudant/fabric repository. Its obvious in
hindsight
Github user davisp commented on the issue:
https://github.com/apache/couchdb-couch/pull/185
Good work and persistence, @jaydoane!
---
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 issue:
https://github.com/apache/couchdb-couch/pull/185
+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/pull/185
Yep, +1 to squashing with that commit message
---
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-couch/pull/185
Oh, and we'll want to squash this down into a single commit that has a good
explanation of the change and the basics of how it works.
---
If your project is set up for it, you can reply
1 - 100 of 285 matches
Mail list logo
