You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Bessenyei Balázs Donát <be...@apache.org> on 2021/02/01 17:15:30 UTC
Re: [VOTE] Set a finite default for max_attachment_size
The purpose of this vote / PR is to set _some_ finite default. I went
with 1G as I assumed that would not break anyone's production system.
I'd support decreasing that limit over time.
The vote has been open for 72 hours now, but I believe it still needs
two more +1s to pass.
Donat
On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
>
> This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process.
>
> Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me.
>
>
> Eric
>
>
> > On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org> wrote:
> >
> > Hi,
> >
> > I think a gigabyte is _very_ generous given our experience of this feature in practice.
> >
> > In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit.
> >
> > I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1 gib today, I’d be fairly surprised if it even works.
> >
> > B.
> >
> >> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
> >>
> >> There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop.
> >>
> >> Also 1G limit seems arbitrary - how was it choosen?
> >>
> >>
> >> Thanks,
> >> Eric
> >>
> >>
> >>
> >>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <be...@apache.org> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
> >>> finite default for max_attachment_size .
> >>> The PR is approved, but as per Ilya's request, I'd like to call for a
> >>> lazy majority vote here.
> >>> The vote will remain open for at least 72 hours from now.
> >>>
> >>> Please let me know if you have any questions, comments or concerns.
> >>>
> >>>
> >>> Donat
> >>
> >
>
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Bessenyei Balázs Donát <be...@apache.org>.
Hi Joan,
> Point of order - when we do 72-hour votes, it's best to not count
weekends in that 72-hours.
I remembered the 72 hours is 72 so that everyone has an opportunity to
chime in regardless of their location / timezone. (Ie. so that there's
at least a fraction of a weekday included for everyone.) The closest
reference I can find is [1].
Nevertheless, I'll do my best to start my next votes on a Monday or
Tuesday so that the weekends don't mess things up.
Thank you for letting me know about this!
Donat
[1]: https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Russell Branca <ru...@chewbranca.com>.
A belated +1.
Infinite attachment size is obviously an oversight, and practically
speaking, I think gigabyte sized attachments are still way too big.
I would love to see a solid binary attachment system with CouchDB, but
neither couch_file nor FDB are likely to be it.
-Russell
On Mon, Feb 1, 2021 at 11:30 AM Joan Touzet <wo...@apache.org> wrote:
> HI Donat,
>
> Point of order - when we do 72-hour votes, it's best to not count
> weekends in that 72-hours. So, since you started on the 28th at 05:00
> UTC, I would have continued the vote until Feb 2 at 05:00 UTC.
>
> That said I am +1 on this too, long overdue.
>
> As to Eric's point, all we need to do is document that the setting can
> be lifted and that we've tested "up to XGB" attachments as working in 3.x.
>
> 4.x change notes will show that the limit is reduced, and my opinion is
> that concomitant with a 4.0 release there will be a new 3.x release that
> lowers the defaults to match 4.x. (This may also need the changes
> mentioned in Robert's other thread that are necessary to allow 3.x <->
> 4.x replication, that's still unclear.) For now, we don't need to reduce
> down to 10MB or 5MB or whatever it is.
>
> -Joan
>
> On 01/02/2021 14:06, Bessenyei Balázs Donát wrote:
> > This vote is now closed as there were three +1s, one +0 and no -1s and
> > the 72 hours is up. I'll merge the PR.
> >
> > Thanks to all who voted!
> >
> >
> > Donat
> >
> >
> > On Mon, Feb 1, 2021 at 7:52 PM Eric Avdey <ei...@eiri.ca> wrote:
> >>
> >> Ok, fair enough, +0 from me with a note that I'd still prefer to see
> this limit aligned with 4.x limits, so users wouldn't have to adjust to
> this change twice.
> >>
> >>
> >> Eric
> >>
> >>> On Feb 1, 2021, at 14:47, Nick Vatamaniuc <va...@gmail.com> wrote:
> >>>
> >>> I am +1 to lowering as it's better than infinity.
> >>>
> >>> But I also see Eric's point. I was surprised a while back just like
> >>> Eric that I could successfully upload >1GB-sized files. So why not
> >>> 0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes
> >>> and file systems (FAT32) since they use ints for file size and
> >>> offsets. Since our attachment won't be saved as is in the file systems
> >>> inside a .couch file 2GB may be too high, so 1GB as a limit makes
> >>> sense to me.
> >>>
> >>> -Nick
> >>>
> >>> On Mon, Feb 1, 2021 at 1:25 PM Paul Davis <pa...@gmail.com>
> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>> Default unlimited seems like an oversight regardless of what we
> change it to.
> >>>>
> >>>> On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey <ei...@eiri.ca> wrote:
> >>>>>
> >>>>> Maybe I didn't express myself clear enough. Setting some finit
> default is not a purpose, it's what you are doing and I'm asking what the
> reason for this change. In other words I'm not asking what are you doing,
> I'm asking why are you doing this.
> >>>>>
> >>>>> Introducing a new limit will be a breaking change to anoyone who
> uploads attachments larger than that limit, obviously, so "assumed 1G is
> large enough" sounds really arbitrary to me without any factual support for
> that assumption.
> >>>>>
> >>>>>
> >>>>> Eric
> >>>>>
> >>>>>
> >>>>>> On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát <be...@apache.org>
> wrote:
> >>>>>>
> >>>>>> The purpose of this vote / PR is to set _some_ finite default. I
> went
> >>>>>> with 1G as I assumed that would not break anyone's production
> system.
> >>>>>> I'd support decreasing that limit over time.
> >>>>>>
> >>>>>> The vote has been open for 72 hours now, but I believe it still
> needs
> >>>>>> two more +1s to pass.
> >>>>>>
> >>>>>>
> >>>>>> Donat
> >>>>>>
> >>>>>> On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
> >>>>>>>
> >>>>>>> This got me curious and I tried to upload Ubuntu image as an
> attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and
> then returned proper 201 response with a new doc revision, which I certanly
> didn't expect. Should say, that 1.4G seems suspiciously similar to a normal
> memory limit for a 32 bit process.
> >>>>>>>
> >>>>>>> Putting this aside, I agree that uploading large attachments is an
> anti-pattern and 1G seems excessive, hence my question. I'd expect this
> number to be based on something and correlating it with a technical limit
> in 4.x makes a lot of sense to me.
> >>>>>>>
> >>>>>>>
> >>>>>>> Eric
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org>
> wrote:
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I think a gigabyte is _very_ generous given our experience of
> this feature in practice.
> >>>>>>>>
> >>>>>>>> In 4.x attachment size will necessarily be much more restrictive,
> so it seems prudent to move toward that limit.
> >>>>>>>>
> >>>>>>>> I don’t think many folks (hopefully no one!) is routinely
> inserting attachments over 1 gib today, I’d be fairly surprised if it even
> works.
> >>>>>>>>
> >>>>>>>> B.
> >>>>>>>>
> >>>>>>>>> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
> >>>>>>>>>
> >>>>>>>>> There is no justification neither here or on the PR for this
> change, i.e. why this is done. Original infinity default was set to
> preserve previous behaviour, this change will inadvertently break workflow
> for users who upload large attachment and haven't set explicit default, so
> why is it fine to do now? There might be some discussion around this
> somewhere, but it'd be nice to include it here for sake of people like me
> who's out of the loop.
> >>>>>>>>>
> >>>>>>>>> Also 1G limit seems arbitrary - how was it choosen?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Eric
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <
> bessbd@apache.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi All,
> >>>>>>>>>>
> >>>>>>>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing
> to set a
> >>>>>>>>>> finite default for max_attachment_size .
> >>>>>>>>>> The PR is approved, but as per Ilya's request, I'd like to call
> for a
> >>>>>>>>>> lazy majority vote here.
> >>>>>>>>>> The vote will remain open for at least 72 hours from now.
> >>>>>>>>>>
> >>>>>>>>>> Please let me know if you have any questions, comments or
> concerns.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Donat
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>
>
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Joan Touzet <wo...@apache.org>.
HI Donat,
Point of order - when we do 72-hour votes, it's best to not count
weekends in that 72-hours. So, since you started on the 28th at 05:00
UTC, I would have continued the vote until Feb 2 at 05:00 UTC.
That said I am +1 on this too, long overdue.
As to Eric's point, all we need to do is document that the setting can
be lifted and that we've tested "up to XGB" attachments as working in 3.x.
4.x change notes will show that the limit is reduced, and my opinion is
that concomitant with a 4.0 release there will be a new 3.x release that
lowers the defaults to match 4.x. (This may also need the changes
mentioned in Robert's other thread that are necessary to allow 3.x <->
4.x replication, that's still unclear.) For now, we don't need to reduce
down to 10MB or 5MB or whatever it is.
-Joan
On 01/02/2021 14:06, Bessenyei Balázs Donát wrote:
> This vote is now closed as there were three +1s, one +0 and no -1s and
> the 72 hours is up. I'll merge the PR.
>
> Thanks to all who voted!
>
>
> Donat
>
>
> On Mon, Feb 1, 2021 at 7:52 PM Eric Avdey <ei...@eiri.ca> wrote:
>>
>> Ok, fair enough, +0 from me with a note that I'd still prefer to see this limit aligned with 4.x limits, so users wouldn't have to adjust to this change twice.
>>
>>
>> Eric
>>
>>> On Feb 1, 2021, at 14:47, Nick Vatamaniuc <va...@gmail.com> wrote:
>>>
>>> I am +1 to lowering as it's better than infinity.
>>>
>>> But I also see Eric's point. I was surprised a while back just like
>>> Eric that I could successfully upload >1GB-sized files. So why not
>>> 0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes
>>> and file systems (FAT32) since they use ints for file size and
>>> offsets. Since our attachment won't be saved as is in the file systems
>>> inside a .couch file 2GB may be too high, so 1GB as a limit makes
>>> sense to me.
>>>
>>> -Nick
>>>
>>> On Mon, Feb 1, 2021 at 1:25 PM Paul Davis <pa...@gmail.com> wrote:
>>>>
>>>> +1
>>>>
>>>> Default unlimited seems like an oversight regardless of what we change it to.
>>>>
>>>> On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey <ei...@eiri.ca> wrote:
>>>>>
>>>>> Maybe I didn't express myself clear enough. Setting some finit default is not a purpose, it's what you are doing and I'm asking what the reason for this change. In other words I'm not asking what are you doing, I'm asking why are you doing this.
>>>>>
>>>>> Introducing a new limit will be a breaking change to anoyone who uploads attachments larger than that limit, obviously, so "assumed 1G is large enough" sounds really arbitrary to me without any factual support for that assumption.
>>>>>
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>>> On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát <be...@apache.org> wrote:
>>>>>>
>>>>>> The purpose of this vote / PR is to set _some_ finite default. I went
>>>>>> with 1G as I assumed that would not break anyone's production system.
>>>>>> I'd support decreasing that limit over time.
>>>>>>
>>>>>> The vote has been open for 72 hours now, but I believe it still needs
>>>>>> two more +1s to pass.
>>>>>>
>>>>>>
>>>>>> Donat
>>>>>>
>>>>>> On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
>>>>>>>
>>>>>>> This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process.
>>>>>>>
>>>>>>> Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me.
>>>>>>>
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>>
>>>>>>>> On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think a gigabyte is _very_ generous given our experience of this feature in practice.
>>>>>>>>
>>>>>>>> In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit.
>>>>>>>>
>>>>>>>> I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1 gib today, I’d be fairly surprised if it even works.
>>>>>>>>
>>>>>>>> B.
>>>>>>>>
>>>>>>>>> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
>>>>>>>>>
>>>>>>>>> There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop.
>>>>>>>>>
>>>>>>>>> Also 1G limit seems arbitrary - how was it choosen?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <be...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
>>>>>>>>>> finite default for max_attachment_size .
>>>>>>>>>> The PR is approved, but as per Ilya's request, I'd like to call for a
>>>>>>>>>> lazy majority vote here.
>>>>>>>>>> The vote will remain open for at least 72 hours from now.
>>>>>>>>>>
>>>>>>>>>> Please let me know if you have any questions, comments or concerns.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Donat
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Bessenyei Balázs Donát <be...@apache.org>.
This vote is now closed as there were three +1s, one +0 and no -1s and
the 72 hours is up. I'll merge the PR.
Thanks to all who voted!
Donat
On Mon, Feb 1, 2021 at 7:52 PM Eric Avdey <ei...@eiri.ca> wrote:
>
> Ok, fair enough, +0 from me with a note that I'd still prefer to see this limit aligned with 4.x limits, so users wouldn't have to adjust to this change twice.
>
>
> Eric
>
> > On Feb 1, 2021, at 14:47, Nick Vatamaniuc <va...@gmail.com> wrote:
> >
> > I am +1 to lowering as it's better than infinity.
> >
> > But I also see Eric's point. I was surprised a while back just like
> > Eric that I could successfully upload >1GB-sized files. So why not
> > 0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes
> > and file systems (FAT32) since they use ints for file size and
> > offsets. Since our attachment won't be saved as is in the file systems
> > inside a .couch file 2GB may be too high, so 1GB as a limit makes
> > sense to me.
> >
> > -Nick
> >
> > On Mon, Feb 1, 2021 at 1:25 PM Paul Davis <pa...@gmail.com> wrote:
> >>
> >> +1
> >>
> >> Default unlimited seems like an oversight regardless of what we change it to.
> >>
> >> On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey <ei...@eiri.ca> wrote:
> >>>
> >>> Maybe I didn't express myself clear enough. Setting some finit default is not a purpose, it's what you are doing and I'm asking what the reason for this change. In other words I'm not asking what are you doing, I'm asking why are you doing this.
> >>>
> >>> Introducing a new limit will be a breaking change to anoyone who uploads attachments larger than that limit, obviously, so "assumed 1G is large enough" sounds really arbitrary to me without any factual support for that assumption.
> >>>
> >>>
> >>> Eric
> >>>
> >>>
> >>>> On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát <be...@apache.org> wrote:
> >>>>
> >>>> The purpose of this vote / PR is to set _some_ finite default. I went
> >>>> with 1G as I assumed that would not break anyone's production system.
> >>>> I'd support decreasing that limit over time.
> >>>>
> >>>> The vote has been open for 72 hours now, but I believe it still needs
> >>>> two more +1s to pass.
> >>>>
> >>>>
> >>>> Donat
> >>>>
> >>>> On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
> >>>>>
> >>>>> This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process.
> >>>>>
> >>>>> Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me.
> >>>>>
> >>>>>
> >>>>> Eric
> >>>>>
> >>>>>
> >>>>>> On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I think a gigabyte is _very_ generous given our experience of this feature in practice.
> >>>>>>
> >>>>>> In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit.
> >>>>>>
> >>>>>> I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1 gib today, I’d be fairly surprised if it even works.
> >>>>>>
> >>>>>> B.
> >>>>>>
> >>>>>>> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
> >>>>>>>
> >>>>>>> There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop.
> >>>>>>>
> >>>>>>> Also 1G limit seems arbitrary - how was it choosen?
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Eric
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <be...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>> Hi All,
> >>>>>>>>
> >>>>>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
> >>>>>>>> finite default for max_attachment_size .
> >>>>>>>> The PR is approved, but as per Ilya's request, I'd like to call for a
> >>>>>>>> lazy majority vote here.
> >>>>>>>> The vote will remain open for at least 72 hours from now.
> >>>>>>>>
> >>>>>>>> Please let me know if you have any questions, comments or concerns.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Donat
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
>
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Eric Avdey <ei...@eiri.ca>.
Ok, fair enough, +0 from me with a note that I'd still prefer to see this limit aligned with 4.x limits, so users wouldn't have to adjust to this change twice.
Eric
> On Feb 1, 2021, at 14:47, Nick Vatamaniuc <va...@gmail.com> wrote:
>
> I am +1 to lowering as it's better than infinity.
>
> But I also see Eric's point. I was surprised a while back just like
> Eric that I could successfully upload >1GB-sized files. So why not
> 0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes
> and file systems (FAT32) since they use ints for file size and
> offsets. Since our attachment won't be saved as is in the file systems
> inside a .couch file 2GB may be too high, so 1GB as a limit makes
> sense to me.
>
> -Nick
>
> On Mon, Feb 1, 2021 at 1:25 PM Paul Davis <pa...@gmail.com> wrote:
>>
>> +1
>>
>> Default unlimited seems like an oversight regardless of what we change it to.
>>
>> On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey <ei...@eiri.ca> wrote:
>>>
>>> Maybe I didn't express myself clear enough. Setting some finit default is not a purpose, it's what you are doing and I'm asking what the reason for this change. In other words I'm not asking what are you doing, I'm asking why are you doing this.
>>>
>>> Introducing a new limit will be a breaking change to anoyone who uploads attachments larger than that limit, obviously, so "assumed 1G is large enough" sounds really arbitrary to me without any factual support for that assumption.
>>>
>>>
>>> Eric
>>>
>>>
>>>> On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát <be...@apache.org> wrote:
>>>>
>>>> The purpose of this vote / PR is to set _some_ finite default. I went
>>>> with 1G as I assumed that would not break anyone's production system.
>>>> I'd support decreasing that limit over time.
>>>>
>>>> The vote has been open for 72 hours now, but I believe it still needs
>>>> two more +1s to pass.
>>>>
>>>>
>>>> Donat
>>>>
>>>> On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
>>>>>
>>>>> This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process.
>>>>>
>>>>> Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me.
>>>>>
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>>> On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think a gigabyte is _very_ generous given our experience of this feature in practice.
>>>>>>
>>>>>> In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit.
>>>>>>
>>>>>> I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1 gib today, I’d be fairly surprised if it even works.
>>>>>>
>>>>>> B.
>>>>>>
>>>>>>> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
>>>>>>>
>>>>>>> There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop.
>>>>>>>
>>>>>>> Also 1G limit seems arbitrary - how was it choosen?
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Eric
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <be...@apache.org> wrote:
>>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
>>>>>>>> finite default for max_attachment_size .
>>>>>>>> The PR is approved, but as per Ilya's request, I'd like to call for a
>>>>>>>> lazy majority vote here.
>>>>>>>> The vote will remain open for at least 72 hours from now.
>>>>>>>>
>>>>>>>> Please let me know if you have any questions, comments or concerns.
>>>>>>>>
>>>>>>>>
>>>>>>>> Donat
>>>>>>>
>>>>>>
>>>>>
>>>
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Nick Vatamaniuc <va...@gmail.com>.
I am +1 to lowering as it's better than infinity.
But I also see Eric's point. I was surprised a while back just like
Eric that I could successfully upload >1GB-sized files. So why not
0.5GB or 2GB? I am thinking 2GB was (is?) a common limit on some OSes
and file systems (FAT32) since they use ints for file size and
offsets. Since our attachment won't be saved as is in the file systems
inside a .couch file 2GB may be too high, so 1GB as a limit makes
sense to me.
-Nick
On Mon, Feb 1, 2021 at 1:25 PM Paul Davis <pa...@gmail.com> wrote:
>
> +1
>
> Default unlimited seems like an oversight regardless of what we change it to.
>
> On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey <ei...@eiri.ca> wrote:
> >
> > Maybe I didn't express myself clear enough. Setting some finit default is not a purpose, it's what you are doing and I'm asking what the reason for this change. In other words I'm not asking what are you doing, I'm asking why are you doing this.
> >
> > Introducing a new limit will be a breaking change to anoyone who uploads attachments larger than that limit, obviously, so "assumed 1G is large enough" sounds really arbitrary to me without any factual support for that assumption.
> >
> >
> > Eric
> >
> >
> > > On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát <be...@apache.org> wrote:
> > >
> > > The purpose of this vote / PR is to set _some_ finite default. I went
> > > with 1G as I assumed that would not break anyone's production system.
> > > I'd support decreasing that limit over time.
> > >
> > > The vote has been open for 72 hours now, but I believe it still needs
> > > two more +1s to pass.
> > >
> > >
> > > Donat
> > >
> > > On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
> > >>
> > >> This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process.
> > >>
> > >> Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me.
> > >>
> > >>
> > >> Eric
> > >>
> > >>
> > >>> On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> I think a gigabyte is _very_ generous given our experience of this feature in practice.
> > >>>
> > >>> In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit.
> > >>>
> > >>> I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1 gib today, I’d be fairly surprised if it even works.
> > >>>
> > >>> B.
> > >>>
> > >>>> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
> > >>>>
> > >>>> There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop.
> > >>>>
> > >>>> Also 1G limit seems arbitrary - how was it choosen?
> > >>>>
> > >>>>
> > >>>> Thanks,
> > >>>> Eric
> > >>>>
> > >>>>
> > >>>>
> > >>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <be...@apache.org> wrote:
> > >>>>>
> > >>>>> Hi All,
> > >>>>>
> > >>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
> > >>>>> finite default for max_attachment_size .
> > >>>>> The PR is approved, but as per Ilya's request, I'd like to call for a
> > >>>>> lazy majority vote here.
> > >>>>> The vote will remain open for at least 72 hours from now.
> > >>>>>
> > >>>>> Please let me know if you have any questions, comments or concerns.
> > >>>>>
> > >>>>>
> > >>>>> Donat
> > >>>>
> > >>>
> > >>
> >
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Paul Davis <pa...@gmail.com>.
+1
Default unlimited seems like an oversight regardless of what we change it to.
On Mon, Feb 1, 2021 at 11:59 AM Eric Avdey <ei...@eiri.ca> wrote:
>
> Maybe I didn't express myself clear enough. Setting some finit default is not a purpose, it's what you are doing and I'm asking what the reason for this change. In other words I'm not asking what are you doing, I'm asking why are you doing this.
>
> Introducing a new limit will be a breaking change to anoyone who uploads attachments larger than that limit, obviously, so "assumed 1G is large enough" sounds really arbitrary to me without any factual support for that assumption.
>
>
> Eric
>
>
> > On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát <be...@apache.org> wrote:
> >
> > The purpose of this vote / PR is to set _some_ finite default. I went
> > with 1G as I assumed that would not break anyone's production system.
> > I'd support decreasing that limit over time.
> >
> > The vote has been open for 72 hours now, but I believe it still needs
> > two more +1s to pass.
> >
> >
> > Donat
> >
> > On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
> >>
> >> This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process.
> >>
> >> Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me.
> >>
> >>
> >> Eric
> >>
> >>
> >>> On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I think a gigabyte is _very_ generous given our experience of this feature in practice.
> >>>
> >>> In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit.
> >>>
> >>> I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1 gib today, I’d be fairly surprised if it even works.
> >>>
> >>> B.
> >>>
> >>>> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
> >>>>
> >>>> There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop.
> >>>>
> >>>> Also 1G limit seems arbitrary - how was it choosen?
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Eric
> >>>>
> >>>>
> >>>>
> >>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <be...@apache.org> wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
> >>>>> finite default for max_attachment_size .
> >>>>> The PR is approved, but as per Ilya's request, I'd like to call for a
> >>>>> lazy majority vote here.
> >>>>> The vote will remain open for at least 72 hours from now.
> >>>>>
> >>>>> Please let me know if you have any questions, comments or concerns.
> >>>>>
> >>>>>
> >>>>> Donat
> >>>>
> >>>
> >>
>
Re: [VOTE] Set a finite default for max_attachment_size
Posted by Eric Avdey <ei...@eiri.ca>.
Maybe I didn't express myself clear enough. Setting some finit default is not a purpose, it's what you are doing and I'm asking what the reason for this change. In other words I'm not asking what are you doing, I'm asking why are you doing this.
Introducing a new limit will be a breaking change to anoyone who uploads attachments larger than that limit, obviously, so "assumed 1G is large enough" sounds really arbitrary to me without any factual support for that assumption.
Eric
> On Feb 1, 2021, at 13:15, Bessenyei Balázs Donát <be...@apache.org> wrote:
>
> The purpose of this vote / PR is to set _some_ finite default. I went
> with 1G as I assumed that would not break anyone's production system.
> I'd support decreasing that limit over time.
>
> The vote has been open for 72 hours now, but I believe it still needs
> two more +1s to pass.
>
>
> Donat
>
> On Thu, Jan 28, 2021 at 10:44 PM Eric Avdey <ei...@eiri.ca> wrote:
>>
>> This got me curious and I tried to upload Ubuntu image as an attachment. Interestingly CouchDB 3.x accepted first 1.4G of 2.8G file and then returned proper 201 response with a new doc revision, which I certanly didn't expect. Should say, that 1.4G seems suspiciously similar to a normal memory limit for a 32 bit process.
>>
>> Putting this aside, I agree that uploading large attachments is an anti-pattern and 1G seems excessive, hence my question. I'd expect this number to be based on something and correlating it with a technical limit in 4.x makes a lot of sense to me.
>>
>>
>> Eric
>>
>>
>>> On Jan 28, 2021, at 16:02, Robert Newson <rn...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> I think a gigabyte is _very_ generous given our experience of this feature in practice.
>>>
>>> In 4.x attachment size will necessarily be much more restrictive, so it seems prudent to move toward that limit.
>>>
>>> I don’t think many folks (hopefully no one!) is routinely inserting attachments over 1 gib today, I’d be fairly surprised if it even works.
>>>
>>> B.
>>>
>>>> On 28 Jan 2021, at 19:42, Eric Avdey <ei...@eiri.ca> wrote:
>>>>
>>>> There is no justification neither here or on the PR for this change, i.e. why this is done. Original infinity default was set to preserve previous behaviour, this change will inadvertently break workflow for users who upload large attachment and haven't set explicit default, so why is it fine to do now? There might be some discussion around this somewhere, but it'd be nice to include it here for sake of people like me who's out of the loop.
>>>>
>>>> Also 1G limit seems arbitrary - how was it choosen?
>>>>
>>>>
>>>> Thanks,
>>>> Eric
>>>>
>>>>
>>>>
>>>>> On Jan 28, 2021, at 01:46, Bessenyei Balázs Donát <be...@apache.org> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> In https://github.com/apache/couchdb/pull/3347 I'm proposing to set a
>>>>> finite default for max_attachment_size .
>>>>> The PR is approved, but as per Ilya's request, I'd like to call for a
>>>>> lazy majority vote here.
>>>>> The vote will remain open for at least 72 hours from now.
>>>>>
>>>>> Please let me know if you have any questions, comments or concerns.
>>>>>
>>>>>
>>>>> Donat
>>>>
>>>
>>