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 <woh...@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 <e...@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 <vatam...@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 <paul.joseph.da...@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 <e...@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 <bes...@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 <e...@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 <rnew...@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 <e...@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 < > bes...@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 > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>> > >> >
