Michael Richardson writes:
Stephen J. Turnbull <steve@turnbull.jp> wrote: > that they're stable. Unfortunately, the email and web > environments are not, and dealing with changes in them is > often quite impractical given the Debian release cycle.
Yes, I'm aware of this tusscle. There are some ways to split this up.
Sure but that's work for the Debian maintainers.
> Not sure what you mean by "Sometimes this goes way on it's > own, but sometimes it does not".Meaning, sometimes whatever has the lock releases it everything proceeds. Sometimes, it's still stuck a few days later, and I restart the mailman daemons.
This sounds to me like your runners are crashing, as Mark suggested. But even if that's resolved, you're still going to have a performance issue (lock contention for seconds or even minutes maybe[1]) even if you don't get stuck for days.
Fair enough. It was not obvious when installing that I should not use sqlite3.
Yeah, there's a sort of warning somewhere that we strongly recommend a full-featured RDBMS system, but we should probably make it a lot more prominent and explain why.
Yes, I'm gonna have to do that. At least I'll start by counting number of records in each table, and then see if there is some systematic lack.
I wonder if the routines in SQLAlchemy are expecting features (such as indexes) from your PostgreSQL DB that sqlite3 doesn't have, and so don't get copied across by pgloader. That kind of thing is why Mark suggests creating the DB by hand, then using Mailman to initialize, and finally do an SQL dump and load of the tables.
Footnotes: [1] Mailman "shouldn't" be holding on to locks while doing time- consuming processing such as sending mail, but I can't promise it doesn't.
-- GNU Mailman consultant (installation, migration, customization) Sirus Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan