On 18 Mar 2021, at 5:05 pm, Abhilash Raj <maxking@asynchronous.in> wrote:
Hi Simon,
On Mar 17, 2021, at 10:16 PM, Simon Coggins <s.coggins@cqu.edu.au> wrote:
Hi,
I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns.
After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning:
DELETE FROM member WHERE member.id = 166814
If I try to run it manually I get the same issue, in psql it never returns. mailman=# explain analyze DELETE FROM member WHERE member.id = 166814; [… 60 seconds passes…] ^CCancel request sent ERROR: canceling statement due to user request CONTEXT: while deleting tuple (2998,72) in relation "member" I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine.
Are you able to retrieve that Member object using API?
This1 the Python code which would try to delete a Member object and I am assuming is being called from syncmembers command. I am not entire sure about what would cause the database to hang, if there was some database constraint that failed, I would imagine some error to be returned.
Ok I think I’m getting closer. It appears to be an open transaction that is locking the database record. While mailman is running, if I try to execute "DELETE FROM member WHERE member.id = 166507;” on the mailman table in psql the query hangs and never returned. But if I shutdown mailman and try to run the query again, it executed immediately. So I’m pretty sure there is an open transaction that is causing the entry to be locked.
One thing you can try is see if you can unsubscribe the user using the API or
mailman shellcommand.You can unsubscribe from API by calling a
DELETEmethod athttp://localhost:9001/3.1/members/<member_id>
This would give us some indication about whether there is some bug in the implementation of syncmembers command or if there is something else going on.
Trying via shell or via API to delete the user all fail and hang. I’m able to receive the user/membership/list data without any issue both via mailman command and via the API.
This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing.
Setup Details: OS: Oracle Linux 7 (Redhat) Installed using pip via virtualenv talking to a local pgsql database on the same box. Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website.
PIP Modules versions: django-mailman3 1.3.5 mailman 3.3.3 mailman-hyperkitty 1.1.0 mailmanclient 3.3.2 postorius 1.3.4 psycopg2-binary 2.8.5
What is the version of sqlalchemy package? There is a new 1.4.0 version that came out recently and is incompatible with Core right now. There are backwards incompatible changes which might need some changes in Core to add support.
SQLAlchemy 1.3.19
RPM packages: postgresql12-12.6-1PGDG.rhel7.x86_64 postgresql12-server-12.6-1PGDG.rhel7.x86_64 postgresql12-libs-12.6-1PGDG.rhel7.x86_64 postgresql12-devel-12.6-1PGDG.rhel7.x86_64
-Simon
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Simon Coggins, Principal Systems Engineer Digital Services Directorate CQUniversity, Lvl 6.14, 160 Ann Street Brisbane, QLD, 4000 Email: s.coggins@cqu.edu.au Web: http://www.cqu.edu.au/