Trying to answer everyone... ;) On Tue, Apr 08, 2025 at 08:03:15PM -0400, Neal Gompa wrote: > > +1 > > (Maybe this should be automated and run once a year automatically?)
I think upstream should handle it somehow. Either by moving processed ones to a bounceevent-archive table or pruning them or something. I can file a bug... On Tue, Apr 08, 2025 at 08:23:11PM -0400, Frank Ch. Eigler via infrastructure wrote: > Hi - > > > This all pointed me to find this 7 year old bug report: > > https://gitlab.com/mailman/mailman/-/issues/343 > > Hopefully abompard finds it a fun blast from the past. :) > > > > Anyhow, a quick fix I think would be: > > > > * Save a copy of the latest database dump that should have that table > > backed up. > > * 'truncate bounceevent' to wipe it > > > > Thoughts? +1s? counter proposals? > > Considered creating an index on the bounceevent.processed column? Yep. And perhaps thats the better short term solution for right now. However, the table still gets rows added to it very often, so it's writing to it a lot. I don't know off hand if in postgres land that has a relation to the size of the table being added to or not. On Wed, Apr 09, 2025 at 09:22:14AM +0200, Tomasz Torcz via infrastructure wrote: > > I suggest creating a hash index on bounceevent.processed, as the > process seem only interested in True values. Yeah, that might be less invasive right now, but see the above about writes. > Next step I'd say DELETE FROM bounceevent bounceevent.processed = true; > before dropping whole table as last resort. Well, thats... the entire table. Most of the time there's no bounce events to process, or only 1-2. I worry there that just deleting them, but leaving the table might cause postgresql to have bloated indexes or the like even tho the table is now pretty small? But I guess a vacuum full would fix that. I also don't understand why they are keeping these... is there some historical value in knowning about a bounce 5 years ago? On Wed, Apr 09, 2025 at 07:37:51AM +0000, Aurelien Bompard via infrastructure wrote: > > > Thoughts? +1s? counter proposals? > > I suggest creating a hash index on bounceevent.processed, as the > > process seem only interested in True values. > > Next step I'd say DELETE FROM bounceevent bounceevent.processed = true; > > before dropping whole table as last resort. > > +1 to that. ok. I can change this to a request to make a index for now. > The fix for this issue should has been merged 5 years ago, is our Mailman > version that old? no. mailman3-3.3.8-3.el9.noarch The way I read that bug is that you reported that table was gigantic, they noticed they weren't doing any bounce processing at all, they fixed that they were not doing any bounce processing at all and closed the bug. I don't think they addressed the orig issue there... On Wed, Apr 09, 2025 at 10:07:31AM +0200, Michal Konecny via infrastructure wrote: > +1 from me > > The bounceevent table also hit me during the migration to mailman3, but > there were instruction how to skip that step and mark all that were already > in the db processed. I assume that processed bounce events should be deleted > from DB after some time as a permanent solution, like once per year or so. Well, I think thats something we should ask upstream. Is there any reason to keep them around? and for how long? I guess based on this I will try adding an index for now. kevin -- _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
