On Sun, 20 Mar 2022 at 13:52, Andrew Dunstan <and...@dunslane.net> wrote:
> > On 3/19/22 14:48, Andres Freund wrote: > > Hi, > > > > On 2022-03-03 13:37:35 +0000, Dave Page wrote: > >> On Thu, 3 Mar 2022 at 13:28, Pavel Borisov <pashkin.e...@gmail.com> > wrote: > >> > >>> The mail system doesn't have the capability to apply different > moderation > >>>> rules for people in that way I'm afraid. > >>>> > >>> Maybe then 2MB for everyone? Otherwise it's not so convenient. Lead to > >>> answers before the questions in the thread [1], seems weird. > >>> > >> Then someone will complain if their patch is 2.1MB! How often are > messages > >> legitimately over 1MB anyway, even with a patch? I don't usually > moderate > >> -hackers, so I don't know if this is a common thing or not. > > I don't think it's actually that rare. But most contributors writing that > > large patchsets know about the limit and work around it - I gzip patches > when > > I see the email getting too large. But it's more annoying to work with > for > > reviewers. > > > > It's somewhat annoying. If you e.g. append a few graphs of performance > changes > > and a patch it's pretty easy to get into the range where compressing > won't > > help anymore. > > > > And sure, any limit may be hit by somebody. But 1MB across the whole > email > > seems pretty low these days. > > > > Of course we could get complaints no matter what level we set the limit > at. I think raising it to 2Mb would be a reasonable experiment. If no > observable evil ensues then leave it that way. If it does then roll it > back. I agree that plain uncompressed patches are easier to deal with in > general. > Thanks for the reminder :-) I've bumped the limit to 2MB. -- Dave Page Blog: https://pgsnake.blogspot.com Twitter: @pgsnake EDB: https://www.enterprisedb.com
