Re: Announcing GitHub Discussions for Apache CouchDB [Beta]

[Joan Touzet]

Hi Piotr,

We learned of the feature based on friends who are testing the feature 
in private beta, in places like the JavaScript React community:


  https://github.com/vercel/next.js/discussions

That page shows some of the upcoming features in Discussions, currently 
hard coded for that community.


You'll have to talk to ASF Infrastructure if you want to experiment with 
this feature. Open a JIRA ticket with them; they are the gatekeepers.


-Joan "now in the correct Channel" Touzet

On 2020-06-09 5:22 p.m., Piotr Zarzycki wrote:

Hi Guys,

I'm PMC in a different Apache project and I was wondering - what required
actually to switch ON Discussion on GH? How idea started?

Thanks,
Piotr


On Tue, Jun 9, 2020, 10:48 PM Alessio 'Blaster' Biancalana <
dottorblas...@apache.org> wrote:


Woh! This is huuuge!
Thanks for making this happen :-)

Alessio

On Tue, Jun 9, 2020 at 8:14 PM Joan Touzet  wrote:


Hi everyone,

Thanks to some personal connections and the support of ASF Infra, Apache
CouchDB now has GitHub Discussions enabled on our repository:

https://github.com/apache/couchdb/discussions

Right now, we're beta testing this (in conjunction with MS/GitHub and
the ASF) as a new user support channel. You may have already seen us
move a few Issues over to Discussions, where they now belong.

We're hoping that this gives people a friendlier way to build community
around CouchDB, one that doesn't require mailing list membership or
joining a possibly-intimidating Slack channel. Please feel free to use
the Discussions to ask for help with CouchDB, share ideas, show us what
you've done with CouchDB, offer thanks to the team, or post things you
learned and want to share with others.

One key feature is that we hope to give more recognition and affordance
to our non-committer contributors through the Discussions platform. Stay
tuned for more info.

As more Discussions features become available, we'll make use of them to
customize our space there, including linking to our project
"bylaws"/rules and code of conduct.

Two caveats: Right now, there is no webhook availability for
Discussions, which means we can't mirror activity there to our user@
mailing lists. We've been told this will arrive around the time
Discussions leaves private beta.

The other: Please remember that all discussion of project *direction*
and *decision making* must occur on the dev@ mailing list. It's fine to
link to threads in Discussions to help start the decision making
process, just the same as we do with Slack, Stack Overflow, etc. today.

I hope this comes as welcome news to everyone. I'm pretty excited about
it! Special thanks to Jan Lehnardt, who helped get this enabled for us,
and Garren Smith, who started the discussion months ago about moving out
of the twentieth century for community building.

-Joan "I'm a woman. I can change. If I have to. I guess." Touzet

Re: Announcing GitHub Discussions for Apache CouchDB [Beta]

[Piotr Zarzycki]

Hi Guys,

I'm PMC in a different Apache project and I was wondering - what required
actually to switch ON Discussion on GH? How idea started?

Thanks,
Piotr


On Tue, Jun 9, 2020, 10:48 PM Alessio 'Blaster' Biancalana <
dottorblas...@apache.org> wrote:

> Woh! This is huuuge!
> Thanks for making this happen :-)
>
> Alessio
>
> On Tue, Jun 9, 2020 at 8:14 PM Joan Touzet  wrote:
>
> > Hi everyone,
> >
> > Thanks to some personal connections and the support of ASF Infra, Apache
> > CouchDB now has GitHub Discussions enabled on our repository:
> >
> >https://github.com/apache/couchdb/discussions
> >
> > Right now, we're beta testing this (in conjunction with MS/GitHub and
> > the ASF) as a new user support channel. You may have already seen us
> > move a few Issues over to Discussions, where they now belong.
> >
> > We're hoping that this gives people a friendlier way to build community
> > around CouchDB, one that doesn't require mailing list membership or
> > joining a possibly-intimidating Slack channel. Please feel free to use
> > the Discussions to ask for help with CouchDB, share ideas, show us what
> > you've done with CouchDB, offer thanks to the team, or post things you
> > learned and want to share with others.
> >
> > One key feature is that we hope to give more recognition and affordance
> > to our non-committer contributors through the Discussions platform. Stay
> > tuned for more info.
> >
> > As more Discussions features become available, we'll make use of them to
> > customize our space there, including linking to our project
> > "bylaws"/rules and code of conduct.
> >
> > Two caveats: Right now, there is no webhook availability for
> > Discussions, which means we can't mirror activity there to our user@
> > mailing lists. We've been told this will arrive around the time
> > Discussions leaves private beta.
> >
> > The other: Please remember that all discussion of project *direction*
> > and *decision making* must occur on the dev@ mailing list. It's fine to
> > link to threads in Discussions to help start the decision making
> > process, just the same as we do with Slack, Stack Overflow, etc. today.
> >
> > I hope this comes as welcome news to everyone. I'm pretty excited about
> > it! Special thanks to Jan Lehnardt, who helped get this enabled for us,
> > and Garren Smith, who started the discussion months ago about moving out
> > of the twentieth century for community building.
> >
> > -Joan "I'm a woman. I can change. If I have to. I guess." Touzet
> >
>

Re: Announcing GitHub Discussions for Apache CouchDB [Beta]

[Alessio 'Blaster' Biancalana]

Woh! This is huuuge!
Thanks for making this happen :-)

Alessio

On Tue, Jun 9, 2020 at 8:14 PM Joan Touzet  wrote:

> Hi everyone,
>
> Thanks to some personal connections and the support of ASF Infra, Apache
> CouchDB now has GitHub Discussions enabled on our repository:
>
>https://github.com/apache/couchdb/discussions
>
> Right now, we're beta testing this (in conjunction with MS/GitHub and
> the ASF) as a new user support channel. You may have already seen us
> move a few Issues over to Discussions, where they now belong.
>
> We're hoping that this gives people a friendlier way to build community
> around CouchDB, one that doesn't require mailing list membership or
> joining a possibly-intimidating Slack channel. Please feel free to use
> the Discussions to ask for help with CouchDB, share ideas, show us what
> you've done with CouchDB, offer thanks to the team, or post things you
> learned and want to share with others.
>
> One key feature is that we hope to give more recognition and affordance
> to our non-committer contributors through the Discussions platform. Stay
> tuned for more info.
>
> As more Discussions features become available, we'll make use of them to
> customize our space there, including linking to our project
> "bylaws"/rules and code of conduct.
>
> Two caveats: Right now, there is no webhook availability for
> Discussions, which means we can't mirror activity there to our user@
> mailing lists. We've been told this will arrive around the time
> Discussions leaves private beta.
>
> The other: Please remember that all discussion of project *direction*
> and *decision making* must occur on the dev@ mailing list. It's fine to
> link to threads in Discussions to help start the decision making
> process, just the same as we do with Slack, Stack Overflow, etc. today.
>
> I hope this comes as welcome news to everyone. I'm pretty excited about
> it! Special thanks to Jan Lehnardt, who helped get this enabled for us,
> and Garren Smith, who started the discussion months ago about moving out
> of the twentieth century for community building.
>
> -Joan "I'm a woman. I can change. If I have to. I guess." Touzet
>

Re: How to work with Indexes

[ermouth]

> Just remember to ask the selector in the same order as they are indexed

It doesn’t guarantee appropriate index will be used, however providing
use_index param might help.
https://docs.couchdb.org/en/2.3.1/api/database/find.html?highlight=use_index

ermouth


вт, 9 июн. 2020 г. в 15:18, Andrea Brancatelli
:

> As ermouth said the best approach is to use the explain feature of
> Fauxton / Photon.
>
> Couch tries to guess what's the best index to use for any case so you
> don't necessarily need to build complex indexes, if you ask for more
> selectors than the indexed ones usually it picks an index and then scan
> the documents to apply the subselectors.
>
> Yet I must admit I feel the logic behind it a bit entropic and
> cumbersome.
>
> Just remember to ask the selector in the same order as they are indexed,
> even for partial indexes.
>
> Like a select for { fieldA, fieldB, fieldC } and an index for { fieldA,
> fieldB } would work as you expect, but if the index was on { fieldA,
> fieldC } it won't get used.
>
> On the contrary I don't think Couch is (yet?) able to to Union between
> indexes, so if you have index { fieldA } index { fieldB } and ask for
> select { fieldA, fieldB } only index { fieldA } will be used and then
> all the documents will be processed to find the subset.
>
> That's my empiric deduction from some usage, but someone with the hands
> on the code can probably correct me.
>
> ---
>
> Andrea Brancatelli
>
> On 2020-06-09 13:21, Piotr Zarzycki wrote:
>
> > Hi  Aurélien,
> >
> > It is not actually about any specific case. My questions are just helpers
> > to truly understand what approach we should take in our database. I just
> > have hope that I will get more understanding to get answer to some cases.
> >
> > Answer to your questions inline.
> >
> > wt., 9 cze 2020 o 13:04 Aurélien Bénel 
> napisał(a):
> >
> > Hi Piotr,
> >
> > Let's say that I have created two indexes for fields "docType" and "age":
> > (...)
> > My question is - How CouchDb will behave in case when I'm searching my db
> > using both fields when there are two indexes which contains the same
> > fields?
> > To answer your question (at least with js views, I don't use Mango but I
> > suppose it to be similar),
> > we need more details:
> >
> > - Are both fields variable parameters ? Or is one of them a constant?
>
> I think both cases I would consider. However the first one would be that
> I'm searching using both fields as a variable parameters. I'm not sure
> about constant question. I think non of those fields are constant - I
> mean
> from the database point of view docType won't change in the document
> that's
> for sure.
>
> > - Will both parameters be always set ? If not, which one might be unset?
> >
> > Let's assume that it always will, but like I said what if I'm looking
> only
>  and searching/querying using docType only ?
>
> > Regards,
> >
> > Aurélien

Re: How to work with Indexes

[Andrea Brancatelli]

As ermouth said the best approach is to use the explain feature of
Fauxton / Photon.

Couch tries to guess what's the best index to use for any case so you
don't necessarily need to build complex indexes, if you ask for more
selectors than the indexed ones usually it picks an index and then scan
the documents to apply the subselectors. 

Yet I must admit I feel the logic behind it a bit entropic and
cumbersome. 

Just remember to ask the selector in the same order as they are indexed,
even for partial indexes. 

Like a select for { fieldA, fieldB, fieldC } and an index for { fieldA,
fieldB } would work as you expect, but if the index was on { fieldA,
fieldC } it won't get used. 

On the contrary I don't think Couch is (yet?) able to to Union between
indexes, so if you have index { fieldA } index { fieldB } and ask for
select { fieldA, fieldB } only index { fieldA } will be used and then
all the documents will be processed to find the subset. 

That's my empiric deduction from some usage, but someone with the hands
on the code can probably correct me. 

---

Andrea Brancatelli

On 2020-06-09 13:21, Piotr Zarzycki wrote:

> Hi  Aurélien,
> 
> It is not actually about any specific case. My questions are just helpers
> to truly understand what approach we should take in our database. I just
> have hope that I will get more understanding to get answer to some cases.
> 
> Answer to your questions inline.
> 
> wt., 9 cze 2020 o 13:04 Aurélien Bénel  napisał(a):
> 
> Hi Piotr,
> 
> Let's say that I have created two indexes for fields "docType" and "age":
> (...)
> My question is - How CouchDb will behave in case when I'm searching my db
> using both fields when there are two indexes which contains the same
> fields? 
> To answer your question (at least with js views, I don't use Mango but I
> suppose it to be similar),
> we need more details:
> 
> - Are both fields variable parameters ? Or is one of them a constant?

I think both cases I would consider. However the first one would be that
I'm searching using both fields as a variable parameters. I'm not sure
about constant question. I think non of those fields are constant - I
mean
from the database point of view docType won't change in the document
that's
for sure.

> - Will both parameters be always set ? If not, which one might be unset?
> 
> Let's assume that it always will, but like I said what if I'm looking only
 and searching/querying using docType only ?

> Regards,
> 
> Aurélien

Re: How to work with Indexes

[Piotr Zarzycki]

Hi  Aurélien,

It is not actually about any specific case. My questions are just helpers
to truly understand what approach we should take in our database. I just
have hope that I will get more understanding to get answer to some cases.

Answer to your questions inline.

wt., 9 cze 2020 o 13:04 Aurélien Bénel  napisał(a):

> Hi Piotr,
>
> > Let's say that I have created two indexes for fields "docType" and "age":
> > (...)
> > My question is - How CouchDb will behave in case when I'm searching my db
> > using both fields when there are two indexes which contains the same
> > fields?
>
> To answer your question (at least with js views, I don't use Mango but I
> suppose it to be similar),
> we need more details:
>
> - Are both fields variable parameters ? Or is one of them a constant?
>

I think both cases I would consider. However the first one would be that
I'm searching using both fields as a variable parameters. I'm not sure
about constant question. I think non of those fields are constant - I mean
from the database point of view docType won't change in the document that's
for sure.


> - Will both parameters be always set ? If not, which one might be unset?
>
> Let's assume that it always will, but like I said what if I'm looking only
and searching/querying using docType only ?


>
> Regards,
>
> Aurélien



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: How to work with Indexes

[Aurélien Bénel]

Hi Piotr,

> Let's say that I have created two indexes for fields "docType" and "age":
> (...)
> My question is - How CouchDb will behave in case when I'm searching my db
> using both fields when there are two indexes which contains the same
> fields?

To answer your question (at least with js views, I don't use Mango but I 
suppose it to be similar), 
we need more details:

- Are both fields variable parameters ? Or is one of them a constant?
- Will both parameters be always set ? If not, which one might be unset? 


Regards,

Aurélien

Re: How to work with Indexes

[ermouth]

> How CouchDb will behave in case when I'm searching my db
> using both fields when there are two indexes which contains the same

Consider using Explain button, it exists both in Fauxton and Photon and
located in Mango qry panel. Very likely you will discover that CouchDB by
default does not use any of indexes.

ermouth

Re: How to work with Indexes

[Piotr Zarzycki]

I have found following article [1], which describes how indexes are working
- I hope it is still true. In the light of what I'm reading there I have a
question:

Let's say that I have created two indexes for fields "docType" and "age":

{
   "index": {
  "fields": [
 "docType"
  ]
   },
   "name": "foo-json-index",
   "type": "json"
},
{
   "index": {
  "fields": [
 "docType",
 "age "
  ]
   },
   "name": "foo-json-index",
   "type": "json"
}

My question is - How CouchDb will behave in case when I'm searching my db
using both fields when there are two indexes which contains the same
fields?

Let's say I have: doceType == "form" && age == 32

[1] https://dx13.co.uk/articles/2019/11/08/couchdb-mango-indexes/

Thanks,
Piotr

pt., 5 cze 2020 o 11:34 Piotr Zarzycki 
napisał(a):

> Hi Adam,
>
> Thank you for your response. I would like to go a bit deeper into that
> idea. I'm definitely not an expert on CouchDb - I would say very beginner.
> :)
> If I will have let's say 100 different type of requests in my app and I
> will create indexes for all of them. Rather if I will have one JSON object
> in CouchDb and I will create in Fauxton for each property Index, cause I
> each of my requests related to that object will need that or I will just
> feel that is needed  - Can it be some bad implication of doing that ?
>
> Thanks,
> Piotr
>
>
> czw., 4 cze 2020 o 16:06 Adam Kocoloski  napisał(a):
>
>> Hi Piotr,
>>
>> To first order, yes, I’d try to have every query an application issues be
>> satisfied by an index.
>>
>> If you’ve got some queries that you run infrequently in the background
>> those may not warrant an index, as the resources required to keep the index
>> up-to-date would be greater than the cost of just scanning the entire
>> database.
>>
>> Cheers, Adam
>>
>> > On Jun 4, 2020, at 8:53 AM, Piotr Zarzycki 
>> wrote:
>> >
>> > Hello everyone,
>> >
>> > We are building JS based application which storing data in CouchDb. It
>> is a
>> > greenfield application in case of front end and database structure. I
>> would
>> > use some examples at the beginning.
>> >
>> > I have some selector which gets me data from db:
>> >
>> > const q = {
>> >  selector: {
>> >historyId: document.historyId,
>> >  },
>> >  sort: [{ version: "desc" }],
>> >  limit: 500,
>> >};
>> >
>> >
>> > In the results I will get data along with warning:
>> >
>> > "warning": "no matching index found, create an index to optimize query
>> time"
>> >
>> >
>> > I can easily get rid of that warning by adding using Fauxton index:
>> >
>> > {
>> >   "index": {
>> >  "fields": [
>> > "historyId"
>> >  ]
>> >   },
>> >   "name": "historyId-json-index",
>> >   "type": "json"
>> > }
>> >
>> >
>> > My question is - How do you guys approach to working with indexes ?
>> Should
>> > I add it to each query which I'm doing ?
>> >
>> > Thoughts about approaches would be much appreciated. :)
>> >
>> > Thanks,
>> > --
>> >
>> > Piotr Zarzycki
>> >
>> > Patreon: *https://www.patreon.com/piotrzarzycki
>> > *
>>
>>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: couchdb file corruption

[Jan Lehnardt]

Hi Sharath,

the error you are seeing originates in CouchDB’s file checksumming
feature[1]. When writing a block of data to disk, in either a
database or a view index, CouchDB also stores a checksum of the
block. When reading the block later, it checks if the stored
checksum and the newly read block still match. This is to prevent
hard drive errors sneaking into your database.

In your case, a block in a view index doesn’t match its checksum
anymore. The reasons for this could be manifold, but all of them
will have resulted in a bit or more on your storage device having
changed values behind CouchDB’s back.

To get back to working views, you can delete the index files and
rebuild them.

But more importantly:

1. do triple check what could have caused that block to go bad.
You don’t want to have this happen to your database files.

2. triple check your backups are up to date and restorable.

[1]: 
https://github.com/apache/couchdb/blob/3505281559513e2922484ebf0996a8846dcc0a34/src/couch/src/couch_file.erl#L173-L188

Best
Jan
—

> On 9. Jun 2020, at 02:44, Sharath  wrote:
> 
> Hi,
> 
> I'm encountering a file corruption in CouchDb 2.3.1 running on Ubuntu
> 18.04.1 LTS.
> 
> The disk store is an ext4 SSD.
> 
> I'm unable to access the view and couch logs shows the error below.
> 
> Is there a way of knowing which view is corrupt (I have a few databases).
> 
> I'm thinking of deleting all the views and recreating them - would that
> work?
> 
> thanks!
> 
> error 1:
> [emergency] 2020-06-09T00:33:10.122474Z couchdb@127.0.0.1 <0.1427.0>
>  File corruption in <0.951.0> at position 2668802729
> [error] 2020-06-09T00:33:10.123271Z couchdb@127.0.0.1 <0.1392.0> 9f5e486e35
> rexi_server: from: couchdb@127.0.0.1(<0.758.0>) mfa: fabric_rpc:map_view/5
> throw:{file_corruption,<<"file corruption">>}
> [{couch_mrview_util,get_view_index_state,5,[{file,"src/couch_mrview_util.erl"},{line,137}]},{couch_mrview_util,get_view,4,[{file,"src/couch_mrview_util.erl"},{line,81}]},{couch_mrview,query_view,6,[{file,"src/couch_mrview.erl"},{line,247}]},{rexi_server,init_p,3,[{file,"src/rexi_server.erl"},{line,140}]}]
> [error] 2020-06-09T00:33:10.123712Z couchdb@127.0.0.1 <0.758.0> 9f5e486e35
> req_err(4089041121) file_corruption : file corruption
>[<<"couch_mrview_util:get_view_index_state/5
> L137">>,<<"couch_mrview_util:get_view/4 L81">>,<<"couch_mrview:query_view/6
> L247">>,<<"rexi_server:init_p/3 L140">>]
> [notice] 2020-06-09T00:33:10.124065Z couchdb@127.0.0.1 <0.758.0> 9f5e486e35
> 192.168.0.13:5984 192.168.0.8 admin GET
> /stock/_design/company/_view/getallamexcompanies?reduce=false=0=101
> 500 ok 
> [error] 2020-06-09T00:33:11.129465Z couchdb@127.0.0.1 <0.1419.0> 
> gen_server <0.1419.0> terminated with reason: no match of right hand value
> eof at couch_file:read_raw_iolist_int/3(line:627) <=
> couch_file:handle_call/3(line:449) <=
> gen_server:try_handle_call/4(line:615) <= gen_server:handle_msg/5(line:647)
> <= proc_lib:init_p_do_apply/3(line:247)
>  last msg: {pread_iolist,1190244510}
> state:
> [{data,[{"State",{file,{file_descriptor,prim_file,{#Port<0.7921>,106}},false,1767501252,undefined,infinity}},{"InitialFilePath","/data/couchdb/.shards/8000-9fff/stock.1584663325_design/mrview/856ffe4a2101b41233877c86e8e3f8e6.view"}]}]
>extra: []
> [error] 2020-06-09T00:33:11.132250Z couchdb@127.0.0.1 <0.1419.0> 
> CRASH REPORT Process  (<0.1419.0>) with 1 neighbors exited with reason: no
> match of right hand value eof at couch_file:read_raw_iolist_int/3(line:627)
> <= couch_file:handle_call/3(line:449) <=
> gen_server:try_handle_call/4(line:615) <= gen_server:handle_msg/5(line:647)
> <= proc_lib:init_p_do_apply/3(line:247) at gen_server:terminate/7(line:812)
> <= proc_lib:init_p_do_apply/3(line:247); initial_call:
> {couch_file,init,['Argument__1']}, ancestors: [<0.1408.0>,<0.1407.0>],
> messages: [], links: [<0.1408.0>], dictionary:
> [{couch_file_fd,{{file_descriptor,prim_file,{#Port<0.7921>,106}},"/dat..."}},...],
> trap_exit: false, status: running, heap_size: 6772, stack_size: 27,
> reductions: 573398
> [error] 2020-06-09T00:33:11.132607Z couchdb@127.0.0.1 <0.1432.0> 
> gen_server <0.1432.0> terminated with reason: no match of right hand value
> eof at couch_file:read_raw_iolist_int/3(line:627) <=
> couch_file:handle_call/3(line:449) <=
> gen_server:try_handle_call/4(line:615) <= gen_server:handle_msg/5(line:647)
> <= proc_lib:init_p_do_apply/3(line:247)
>  last msg:
> {'EXIT',<0.1408.0>,{{badmatch,eof},[{couch_file,read_raw_iolist_int,3,[{file,"src/couch_file.erl"},{line,627}]},{couch_file,handle_call,3,[{file,"src/couch_file.erl"},{line,449}]},{gen_server,try_handle_call,4,[{file,"gen_server.erl"},{line,615}]},{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,647}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}}
> state: {st,<0.1408.0>,couch_mrview_index,undefined}
>extra: []
> 
> 
> error 2:
> [error] 2020-06-09T00:40:25.580012Z 

Re: couchdb file corruption

[Kiril Stankov]

Hi,

Couch (Erlang) log files are something only few chosen ones can
understand, and you will probably find someone on the list. I always
wondered why it shall be so hard to have a log line saying something like:
read past eof in file foo.bar. File seems to be corrupted.

IMHO, the problem is in

"/data/couchdb/.shards/8000-9fff/stock.1584663325_design/mrview/856ffe4a2101b41233877c86e8e3f8e6.view"

which is a view file for the stock DB?

I guess that, yes, you can delete the view and try to recreate it.
Otherwise - try replicating the data to another instance, and then
delete the entire db, replicate it back and create the view again.

Best,
Kiril.

On 9.06.20 г. 3:44 ч., Sharath wrote:
> Hi,
>
> I'm encountering a file corruption in CouchDb 2.3.1 running on Ubuntu
> 18.04.1 LTS.
>
> The disk store is an ext4 SSD.
>
> I'm unable to access the view and couch logs shows the error below.
>
> Is there a way of knowing which view is corrupt (I have a few databases).
>
> I'm thinking of deleting all the views and recreating them - would that
> work?
>
> thanks!
>
> error 1:
> [emergency] 2020-06-09T00:33:10.122474Z couchdb@127.0.0.1 <0.1427.0>
>  File corruption in <0.951.0> at position 2668802729
> [error] 2020-06-09T00:33:10.123271Z couchdb@127.0.0.1 <0.1392.0> 9f5e486e35
> rexi_server: from: couchdb@127.0.0.1(<0.758.0>) mfa: fabric_rpc:map_view/5
> throw:{file_corruption,<<"file corruption">>}
> [{couch_mrview_util,get_view_index_state,5,[{file,"src/couch_mrview_util.erl"},{line,137}]},{couch_mrview_util,get_view,4,[{file,"src/couch_mrview_util.erl"},{line,81}]},{couch_mrview,query_view,6,[{file,"src/couch_mrview.erl"},{line,247}]},{rexi_server,init_p,3,[{file,"src/rexi_server.erl"},{line,140}]}]
> [error] 2020-06-09T00:33:10.123712Z couchdb@127.0.0.1 <0.758.0> 9f5e486e35
> req_err(4089041121) file_corruption : file corruption
> [<<"couch_mrview_util:get_view_index_state/5
> L137">>,<<"couch_mrview_util:get_view/4 L81">>,<<"couch_mrview:query_view/6
> L247">>,<<"rexi_server:init_p/3 L140">>]
> [notice] 2020-06-09T00:33:10.124065Z couchdb@127.0.0.1 <0.758.0> 9f5e486e35
> 192.168.0.13:5984 192.168.0.8 admin GET
> /stock/_design/company/_view/getallamexcompanies?reduce=false=0=101
> 500 ok 
> [error] 2020-06-09T00:33:11.129465Z couchdb@127.0.0.1 <0.1419.0> 
> gen_server <0.1419.0> terminated with reason: no match of right hand value
> eof at couch_file:read_raw_iolist_int/3(line:627) <=
> couch_file:handle_call/3(line:449) <=
> gen_server:try_handle_call/4(line:615) <= gen_server:handle_msg/5(line:647)
> <= proc_lib:init_p_do_apply/3(line:247)
>   last msg: {pread_iolist,1190244510}
>  state:
> [{data,[{"State",{file,{file_descriptor,prim_file,{#Port<0.7921>,106}},false,1767501252,undefined,infinity}},{"InitialFilePath","/data/couchdb/.shards/8000-9fff/stock.1584663325_design/mrview/856ffe4a2101b41233877c86e8e3f8e6.view"}]}]
> extra: []
> [error] 2020-06-09T00:33:11.132250Z couchdb@127.0.0.1 <0.1419.0> 
> CRASH REPORT Process  (<0.1419.0>) with 1 neighbors exited with reason: no
> match of right hand value eof at couch_file:read_raw_iolist_int/3(line:627)
> <= couch_file:handle_call/3(line:449) <=
> gen_server:try_handle_call/4(line:615) <= gen_server:handle_msg/5(line:647)
> <= proc_lib:init_p_do_apply/3(line:247) at gen_server:terminate/7(line:812)
> <= proc_lib:init_p_do_apply/3(line:247); initial_call:
> {couch_file,init,['Argument__1']}, ancestors: [<0.1408.0>,<0.1407.0>],
> messages: [], links: [<0.1408.0>], dictionary:
> [{couch_file_fd,{{file_descriptor,prim_file,{#Port<0.7921>,106}},"/dat..."}},...],
> trap_exit: false, status: running, heap_size: 6772, stack_size: 27,
> reductions: 573398
> [error] 2020-06-09T00:33:11.132607Z couchdb@127.0.0.1 <0.1432.0> 
> gen_server <0.1432.0> terminated with reason: no match of right hand value
> eof at couch_file:read_raw_iolist_int/3(line:627) <=
> couch_file:handle_call/3(line:449) <=
> gen_server:try_handle_call/4(line:615) <= gen_server:handle_msg/5(line:647)
> <= proc_lib:init_p_do_apply/3(line:247)
>   last msg:
> {'EXIT',<0.1408.0>,{{badmatch,eof},[{couch_file,read_raw_iolist_int,3,[{file,"src/couch_file.erl"},{line,627}]},{couch_file,handle_call,3,[{file,"src/couch_file.erl"},{line,449}]},{gen_server,try_handle_call,4,[{file,"gen_server.erl"},{line,615}]},{gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,647}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}}
>  state: {st,<0.1408.0>,couch_mrview_index,undefined}
> extra: []
>
>
> error 2:
> [error] 2020-06-09T00:40:25.580012Z couchdb@127.0.0.1 <0.3409.0> 
> gen_server <0.3409.0> terminated with reason: no match of right hand value
> eof at couch_file:read_raw_iolist_int/3(line:627) <=
> couch_file:handle_call/3(line:449) <=
> gen_server:try_handle_call/4(line:615) <= gen_server:handle_msg/5(line:647)
> <= proc_lib:init_p_do_apply/3(line:247)
>   last msg: {pread_iolist,1223893408}
>  state:
>