I'm seeing a lot of database locked errors
We switched the mailman database from sqlite to postgresql a while back to minimize any database locking but I'm seeing a lot of errors for the django sqlite database. Is it possible to move that to postgres as well?
16:18:39 [Q] ERROR Failed [compute_thread_positions] - database is locked : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 40, in walk_successors obj.save(update_fields=["thread_depth", "thread_order"]) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 743, in save self.save_base(using=using, force_insert=force_insert, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 780, in save_base updated = self._save_table( File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 853, in _save_table updated = self._do_update(base_qs, using, pk_val, values, update_fields, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 903, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 760, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: database is locked
16:18:39 [Q] ERROR Failed [compute_thread_positions] - database is locked : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 40, in walk_successors obj.save(update_fields=["thread_depth", "thread_order"]) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 743, in save self.save_base(using=using, force_insert=force_insert, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 780, in save_base updated = self._save_table( File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 853, in _save_table updated = self._do_update(base_qs, using, pk_val, values, update_fields, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 903, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 760, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: database is locked
16:18:39 [Q] INFO Process-1:4 processing [compute_thread_positions] 16:18:39 [Q] ERROR Failed [compute_thread_positions] - database is locked : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 40, in walk_successors obj.save(update_fields=["thread_depth", "thread_order"]) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 743, in save self.save_base(using=using, force_insert=force_insert, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 780, in save_base updated = self._save_table( File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 853, in _save_table updated = self._do_update(base_qs, using, pk_val, values, update_fields, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 903, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 760, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: database is locked
16:18:39 [Q] INFO Processed [compute_thread_positions] 16:18:44 [Q] INFO Process-1:2 processing [compute_thread_positions] 16:18:44 [Q] INFO Processed [compute_thread_positions] 16:18:44 [Q] INFO Process-1:1 processing [compute_thread_positions] 16:18:44 [Q] INFO Processed [compute_thread_positions] 16:18:44 [Q] INFO Process-1:3 processing [compute_thread_positions] 16:18:44 [Q] INFO Process-1:4 processing [compute_thread_positions] 16:18:44 [Q] ERROR Failed [compute_thread_positions] - database is locked : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 40, in walk_successors obj.save(update_fields=["thread_depth", "thread_order"]) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 743, in save self.save_base(using=using, force_insert=force_insert, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 780, in save_base updated = self._save_table( File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 853, in _save_table updated = self._do_update(base_qs, using, pk_val, values, update_fields, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 903, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 760, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: database is locked
16:18:44 [Q] INFO Processed [compute_thread_positions] 16:18:49 [Q] INFO Process-1:2 processing [compute_thread_positions] 16:18:49 [Q] INFO Process-1:1 processing [compute_thread_positions] 16:18:49 [Q] INFO Process-1:3 processing [compute_thread_positions] 16:18:49 [Q] INFO Process-1:4 processing [compute_thread_positions] 16:18:49 [Q] INFO Process-1:2 processing [compute_thread_positions] 16:18:49 [Q] INFO Process-1:1 processing [compute_thread_positions] 16:18:49 [Q] INFO Processed [compute_thread_positions] 16:18:49 [Q] ERROR Failed [compute_thread_positions] - database is locked : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 40, in walk_successors obj.save(update_fields=["thread_depth", "thread_order"]) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 743, in save self.save_base(using=using, force_insert=force_insert, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 780, in save_base updated = self._save_table( File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 853, in _save_table updated = self._do_update(base_qs, using, pk_val, values, update_fields, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 903, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 760, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: database is locked
16:18:49 [Q] ERROR Failed [compute_thread_positions] - database is locked : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 40, in walk_successors obj.save(update_fields=["thread_depth", "thread_order"]) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 743, in save self.save_base(using=using, force_insert=force_insert, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 780, in save_base updated = self._save_table( File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 853, in _save_table updated = self._do_update(base_qs, using, pk_val, values, update_fields, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 903, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 760, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: database is locked
16:18:49 [Q] INFO Processed [compute_thread_positions] 16:18:49 [Q] INFO Processed [compute_thread_positions] 16:18:49 [Q] INFO Processed [compute_thread_positions] 16:19:39 [Q] INFO Process-1:4 processing [compute_thread_positions] 16:19:39 [Q] INFO Process-1:3 processing [compute_thread_positions] 16:19:39 [Q] INFO Process-1:1 processing [compute_thread_positions] 16:19:39 [Q] ERROR Failed [compute_thread_positions] - database is locked : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 40, in walk_successors obj.save(update_fields=["thread_depth", "thread_order"]) File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 743, in save self.save_base(using=using, force_insert=force_insert, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 780, in save_base updated = self._save_table( File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 853, in _save_table updated = self._do_update(base_qs, using, pk_val, values, update_fields, File "/usr/lib/python3/dist-packages/django/db/models/base.py", line 903, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 760, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1471, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", line 1142, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", line 383, in execute return Database.Cursor.execute(self, query, params) django.db.utils.OperationalError: database is locked
On 9/9/23 13:52, bryan.kartzman@yu.edu wrote:
We switched the mailman database from sqlite to postgresql a while back to minimize any database locking but I'm seeing a lot of errors for the django sqlite database. Is it possible to move that to postgres as well?
Yes. Just configure the database in the DATABASES definition in your Django settings.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks. That worked. I converted the sqlite3 database to a postgresql database and I configured the database in the DATABASES definition of the Django settings. The database lock errors have disappeared but I am getting a Django warning of an improper datetime field. I assume that is related to the database conversion. Any advice for a possible solution? These are the error messages: 16:30:04 [Q] INFO Q Cluster vegan-muppet-fanta-iowa starting. 16:30:04 [Q] INFO Process-1:1 ready for work at 6340 16:30:04 [Q] INFO Process-1:2 ready for work at 6341 16:30:04 [Q] INFO Process-1:3 ready for work at 6342 16:30:04 [Q] INFO Process-1:4 ready for work at 6343 16:30:04 [Q] INFO Process-1:5 monitoring at 6344 16:30:04 [Q] INFO Process-1 guarding cluster vegan-muppet-fanta-iowa 16:30:04 [Q] INFO Process-1:6 pushing tasks at 6345 16:30:04 [Q] INFO Q Cluster vegan-muppet-fanta-iowa running. 16:30:35 [Q] INFO Enqueued 1 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 18:51:09.290256) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:30:35 [Q] INFO Enqueued 2 16:30:35 [Q] INFO Enqueued 3 16:30:35 [Q] INFO Enqueued 4 16:30:35 [Q] INFO Enqueued 5 16:30:35 [Q] INFO Enqueued 6 16:30:35 [Q] INFO Enqueued 7 16:30:35 [Q] INFO Enqueued 8 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 16:11:04.923591) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:30:35 [Q] INFO Enqueued 9 16:30:35 [Q] INFO Enqueued 10 16:30:35 [Q] INFO Enqueued 11 16:30:36 [Q] INFO Enqueued 12 16:30:36 [Q] INFO Enqueued 13 16:30:36 [Q] INFO Enqueued 14 16:30:36 [Q] INFO Enqueued 15 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 20:11:04.923591) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:30:36 [Q] INFO Enqueued 16 16:30:36 [Q] INFO Enqueued 17 16:30:36 [Q] INFO Enqueued 18 16:30:36 [Q] INFO Enqueued 19 16:30:36 [Q] INFO Enqueued 20 16:30:36 [Q] INFO Enqueued 21 16:30:36 [Q] INFO Enqueued 22 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 22:51:09.290256) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:30:36 [Q] INFO Enqueued 23 16:30:36 [Q] INFO Enqueued 24 16:30:36 [Q] INFO Enqueued 25 16:30:36 [Q] INFO Enqueued 26 16:30:36 [Q] INFO Enqueued 27 16:30:36 [Q] INFO Enqueued 28 16:30:36 [Q] INFO Enqueued 29 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 15:11:59.385378) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:30:36 [Q] INFO Enqueued 30 16:30:36 [Q] INFO Enqueued 31 16:30:36 [Q] INFO Enqueued 32 16:30:36 [Q] INFO Enqueued 33 16:30:36 [Q] INFO Enqueued 34 16:30:36 [Q] INFO Enqueued 35 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField OrmQ.lock received a naive datetime (2023-09-11 20:29:35.702222) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:36:12 [Q] INFO Enqueued 36 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 16:00:37.799476) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:36:12 [Q] INFO Enqueued 37 16:36:12 [Q] INFO Enqueued 38 16:36:12 [Q] INFO Enqueued 39 16:36:12 [Q] INFO Enqueued 40 16:36:12 [Q] INFO Enqueued 41 16:36:12 [Q] INFO Enqueued 42 16:41:28 [Q] INFO Enqueued 43 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2020-08-20 04:31:47.179481) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:41:28 [Q] INFO Enqueued 44 16:41:28 [Q] INFO Enqueued 45 16:41:28 [Q] INFO Enqueued 46 16:41:28 [Q] INFO Enqueued 47 16:41:28 [Q] INFO Enqueued 48 16:41:28 [Q] INFO Enqueued 49 16:41:43 [Q] INFO Enqueued 50 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 15:04:40.631493) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:41:43 [Q] INFO Enqueued 51 16:41:43 [Q] INFO Enqueued 52 16:41:43 [Q] INFO Enqueued 53 16:41:43 [Q] INFO Enqueued 54 16:41:43 [Q] INFO Enqueued 55 16:41:43 [Q] INFO Enqueued 56 16:41:55 [Q] INFO Enqueued 57 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 14:48:41.478931) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 16:41:55 [Q] INFO Enqueued 58 16:41:55 [Q] INFO Enqueued 59 16:41:56 [Q] INFO Enqueued 60 16:41:56 [Q] INFO Enqueued 61 16:41:56 [Q] INFO Enqueued 62 16:41:56 [Q] INFO Enqueued 63 17:08:45 [Q] INFO Q Cluster early-lion-kentucky-mockingbird starting. 17:08:45 [Q] INFO Process-1:1 ready for work at 442208 17:08:45 [Q] INFO Process-1:2 ready for work at 442209 17:08:45 [Q] INFO Process-1:3 ready for work at 442210 17:08:45 [Q] INFO Process-1:4 ready for work at 442211 17:08:45 [Q] INFO Process-1:5 monitoring at 442212 17:08:45 [Q] INFO Process-1 guarding cluster early-lion-kentucky-mockingbird 17:08:45 [Q] INFO Process-1:6 pushing tasks at 442213 17:08:45 [Q] INFO Q Cluster early-lion-kentucky-mockingbird running. /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField OrmQ.lock received a naive datetime (2023-09-11 20:29:35.702222) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 17:21:33 [Q] INFO Q Cluster lima-music-jig-twelve starting. 17:21:33 [Q] INFO Process-1:1 ready for work at 590552 17:21:33 [Q] INFO Process-1:2 ready for work at 590553 17:21:33 [Q] INFO Process-1:3 ready for work at 590554 17:21:33 [Q] INFO Process-1:4 ready for work at 590555 17:21:33 [Q] INFO Process-1:5 monitoring at 590556 17:21:33 [Q] INFO Process-1 guarding cluster lima-music-jig-twelve 17:21:33 [Q] INFO Process-1:6 pushing tasks at 590557 17:21:33 [Q] INFO Q Cluster lima-music-jig-twelve running. /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField OrmQ.lock received a naive datetime (2023-09-11 20:29:35.702222) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 17:37:41 [Q] INFO Enqueued 64 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 14:47:07.649808) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 17:37:41 [Q] INFO Enqueued 65 17:37:41 [Q] INFO Enqueued 66 17:37:41 [Q] INFO Enqueued 67 17:37:41 [Q] INFO Enqueued 68 17:37:41 [Q] INFO Enqueued 69 17:37:41 [Q] INFO Enqueued 70 18:06:48 [Q] INFO Enqueued 71 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-08-12 02:12:43.097077) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 18:06:48 [Q] INFO Enqueued 72 18:06:48 [Q] INFO Enqueued 73 18:06:48 [Q] INFO Enqueued 74 18:06:48 [Q] INFO Enqueued 75 18:06:48 [Q] INFO Enqueued 76 18:06:48 [Q] INFO Enqueued 77 19:42:04 [Q] INFO Enqueued 78 /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2022-10-03 18:31:55.715108) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" 19:42:04 [Q] INFO Enqueued 79 19:42:04 [Q] INFO Enqueued 80 19:42:04 [Q] INFO Enqueued 81 19:42:04 [Q] INFO Enqueued 82 19:42:04 [Q] INFO Enqueued 83 19:42:04 [Q] INFO Enqueued 84
On 9/11/23 5:00 PM, bryan.kartzman@yu.edu wrote:
Thanks. That worked. I converted the sqlite3 database to a postgresql database and I configured the database in the DATABASES definition of the Django settings. The database lock errors have disappeared but I am getting a Django warning of an improper datetime field. I assume that is related to the database conversion. Any advice for a possible solution? These are the error messages: ... /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField MailingList.created_at received a naive datetime (2023-06-18 18:51:09.290256) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" ... /usr/lib/python3/dist-packages/django/db/models/fields/__init__.py:1424: RuntimeWarning: DateTimeField OrmQ.lock received a naive datetime (2023-09-11 20:29:35.702222) while time zone support is active. warnings.warn("DateTimeField %s received a naive datetime (%s)" ...
These fields and perhaps others need to be defined in Postgresql as timestamp with time zone. E.g.
Table
"public.hyperkitty_mailinglist"
Column | Type | Collation |
Nullable | Default
------------------------+--------------------------+-----------+----------+----------------------------------------------------
id | integer | | not
null | nextval('hyperkitty_mailinglist_id_seq'::regclass)
name | character varying(254) | | not
null |
display_name | character varying(255) | | not
null |
description | text | |
|
subject_prefix | character varying(255) | | not
null |
archive_policy | integer | | not
null |
created_at | timestamp with time zone | | not
null |
list_id | character varying(254) | |
|
archive_rendering_mode | character varying(255) | |
|
...
Table "public.django_q_ormq"
Column | Type | Collation | Nullable |
Default
---------+--------------------------+-----------+----------+-------------------------------------------
id | integer | | not null |
nextval('django_q_ormq_id_seq'::regclass)
key | character varying(100) | | not null |
payload | text | | not null |
lock | timestamp with time zone | | |
Indexes:
"django_q_ormq_pkey" PRIMARY KEY, btree (id)
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
Thanks. I just saw your response. I actually thought of that myself and converted all timestamp fields in the database to "with time zone" last week with the following code:
ALTER TABLE public.account_emailconfirmation ALTER COLUMN created TYPE TIMESTAMP WITH TIME ZONE USING created AT TIME ZONE 'EDT';
ALTER TABLE public.account_emailconfirmation ALTER COLUMN sent TYPE TIMESTAMP WITH TIME ZONE USING sent AT TIME ZONE 'EDT';
ALTER TABLE public.auth_user ALTER COLUMN last_login TYPE TIMESTAMP WITH TIME ZONE USING last_login AT TIME ZONE 'EDT';
ALTER TABLE public.auth_user ALTER COLUMN date_joined TYPE TIMESTAMP WITH TIME ZONE USING date_joined AT TIME ZONE 'EDT';
ALTER TABLE public.django_admin_log ALTER COLUMN action_time TYPE TIMESTAMP WITH TIME ZONE USING action_time AT TIME ZONE 'EDT';
ALTER TABLE public.django_migrations ALTER COLUMN applied TYPE TIMESTAMP WITH TIME ZONE USING applied AT TIME ZONE 'EDT';
ALTER TABLE public.django_q_ormq ALTER COLUMN lock TYPE TIMESTAMP WITH TIME ZONE USING lock AT TIME ZONE 'EDT';
ALTER TABLE public.django_q_schedule ALTER COLUMN next_run TYPE TIMESTAMP WITH TIME ZONE USING next_run AT TIME ZONE 'EDT';
ALTER TABLE public.django_q_task ALTER COLUMN started TYPE TIMESTAMP WITH TIME ZONE USING started AT TIME ZONE 'EDT';
ALTER TABLE public.django_q_task ALTER COLUMN stopped TYPE TIMESTAMP WITH TIME ZONE USING stopped AT TIME ZONE 'EDT';
ALTER TABLE public.django_session ALTER COLUMN expire_date TYPE TIMESTAMP WITH TIME ZONE USING expire_date AT TIME ZONE 'EDT';
ALTER TABLE public.hyperkitty_email ALTER COLUMN date TYPE TIMESTAMP WITH TIME ZONE USING date AT TIME ZONE 'EDT';
ALTER TABLE public.hyperkitty_email ALTER COLUMN archived_date TYPE TIMESTAMP WITH TIME ZONE USING archived_date AT TIME ZONE 'EDT';
ALTER TABLE public.hyperkitty_lastview ALTER COLUMN view_date TYPE TIMESTAMP WITH TIME ZONE USING view_date AT TIME ZONE 'EDT';
ALTER TABLE public.hyperkitty_mailinglist ALTER COLUMN created_at TYPE TIMESTAMP WITH TIME ZONE USING created_at AT TIME ZONE 'EDT';
ALTER TABLE public.hyperkitty_thread ALTER COLUMN date_active TYPE TIMESTAMP WITH TIME ZONE USING date_active AT TIME ZONE 'EDT';
ALTER TABLE public.postorius_emailtemplate ALTER COLUMN created_at TYPE TIMESTAMP WITH TIME ZONE USING created_at AT TIME ZONE 'EDT';
ALTER TABLE public.postorius_emailtemplate ALTER COLUMN modified_at TYPE TIMESTAMP WITH TIME ZONE USING modified_at AT TIME ZONE 'EDT';
ALTER TABLE public.socialaccount_socialaccount ALTER COLUMN last_login TYPE TIMESTAMP WITH TIME ZONE USING last_login AT TIME ZONE 'EDT';
ALTER TABLE public.socialaccount_socialaccount ALTER COLUMN date_joined TYPE TIMESTAMP WITH TIME ZONE USING date_joined AT TIME ZONE 'EDT';
ALTER TABLE public.socialaccount_socialtoken ALTER COLUMN expires_at TYPE TIMESTAMP WITH TIME ZONE USING expires_at AT TIME ZONE 'EDT';
I'd like to say it worked flawlessly (and it did allow the archives to be displayed, which wasn't happening before, but I'm getting the following two errors (or maybe KeyError 1365 and 1366 are the same error?) every minute:
11:26:23 [Q] ERROR Failed [compute_thread_positions] - 1365 : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 37, in walk_successors obj = graph.nodes[msgid]["obj"] File "/usr/lib/python3/dist-packages/networkx/classes/reportviews.py", line 187, in __getitem__ return self._nodes[n] KeyError: 1365
11:26:23 [Q] ERROR Failed [compute_thread_positions] - 1366 : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 37, in walk_successors obj = graph.nodes[msgid]["obj"] File "/usr/lib/python3/dist-packages/networkx/classes/reportviews.py", line 187, in __getitem__ return self._nodes[n] KeyError: 1366
Is this an error only in the archives or might I also have a problem with other timestamp fields in the database? If its just the archives, is there a simple way to fix it? If no simple way to fix the archives, is there an easy way to erase all list archives? If no easy way to erase all list archives, would deleting all the lists and recreating them remove the archives?
On 9/18/23 8:36 AM, bryan.kartzman@yu.edu wrote:
I'd like to say it worked flawlessly (and it did allow the archives to be displayed, which wasn't happening before, but I'm getting the following two errors (or maybe KeyError 1365 and 1366 are the same error?) every minute:
11:26:23 [Q] ERROR Failed [compute_thread_positions] - 1365 : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 37, in walk_successors obj = graph.nodes[msgid]["obj"] File "/usr/lib/python3/dist-packages/networkx/classes/reportviews.py", line 187, in __getitem__ return self._nodes[n] KeyError: 1365
11:26:23 [Q] ERROR Failed [compute_thread_positions] - 1366 : Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django_q/cluster.py", line 421, in worker res = f(*task["args"], **task["kwargs"]) File "/usr/lib/python3/dist-packages/hyperkitty/tasks.py", line 127, in _compute_thread_positions compute_thread_order_and_depth(thread) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 55, in compute_thread_order_and_depth walk_successors(thread.starting_email.id) File "/usr/lib/python3/dist-packages/hyperkitty/lib/analysis.py", line 37, in walk_successors obj = graph.nodes[msgid]["obj"] File "/usr/lib/python3/dist-packages/networkx/classes/reportviews.py", line 187, in __getitem__ return self._nodes[n] KeyError: 1366
Is this an error only in the archives or might I also have a problem with other timestamp fields in the database? If its just the archives, is there a simple way to fix it? If no simple way to fix the archives, is there an easy way to erase all list archives? If no easy way to erase all list archives, would deleting all the lists and recreating them remove the archives?
The above errors have nothing to do with timestamps.
There are entries in the hyperkitty_thread table with starting_email_id
= 1365 and 1366, i.e., SELECT * FROM hyperkitty_thread WHERE starting_email_id in (1365, 1366);, but there are no entries in the
hyperkitty_email table with id = 1365 or 1366.
You could look at the thread_id for those entries in the hyperkitty_thread table and see if there are entries in the hyperkitty_email table with message_id_hash = those thread_id values. if those entries exist, you can fix this by altering the starting_email_id of those entries to the respective id values for those messages from the hyperkitty_email table.
If those messages don't exist in the hyperkitty_email table, you could just delete the offending entries from the hyperkitty_thread table.
As far as deleting archives is concerned, a Django superuser should have
a Delete Archive button on the top level Hyperkitty view for the list.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Actually, they do exist:
select count(*) FROM hyperkitty_email WHERE id in (1365, 1366); count
2Where does that put us?
And they do have the same thread_id as well:
select a.id, b.starting_email_id, a.message_id_hash, b.thread_id from hyperkitty_email a,hyperkitty_thread b where a.message_id_hash = b.thread_id and a.id = b.starting_email_id and a.id in (1365,1366) ;
id | starting_email_id | message_id_hash | thread_id
------+-------------------+----------------------------------+----------------------------------
1365 | 1365 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7
1366 | 1366 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7
(2 rows)
Some more info: select a.subject from hyperkitty_email a,hyperkitty_thread b where a.message_id_hash = b.thread_id and a.id = b.starting_email_id and a.id in (1365,1366) ; subject
[202309-30660] Re: PHI 3402 link to video [202309-31494] Re: PHI 3402 link to video
And checking the archives for list "202309-31494" it seems that message is out of order (its has an earlier date than the one with the subject "[202309-31494] PHI 3402 link to video", yet it is the reply to that message!):
RECENTLY ACTIVE DISCUSSIONS #1 Where is everyone? Wed Sep 13, 7:36 p.m. 1 0 +0/-0 #2 PHI 3402 link to video Tue Sep 12, 12:26 a.m. 1 1 +0/-0 #3 Re: PHI 3402 link to video Mon Sep 11, 8:26 p.m. 0 -1 +0/-0
It would seem the time on our message (#3) is wrong as it should be later than Tue Sep 12, 12:26 am. Could that be causing the problem? If so, how to fix it?
Sorry for the multitude of posts. I probably should have saved it all up for one post.
I see in the hyperhitty_email table right after the "date" field there is a "timezone" field. I altered the "date" field to "timestamp with time zone" when I changed every timestamp field in the database from "without time zone" to "with time zone". Are there some (like this "date" field) that should have remained "without time zone"?
On 9/18/23 12:33 PM, bryan.kartzman@yu.edu wrote:
Sorry for the multitude of posts. I probably should have saved it all up for one post.
I see in the hyperhitty_email table right after the "date" field there is a "timezone" field. I altered the "date" field to "timestamp with time zone" when I changed every timestamp field in the database from "without time zone" to "with time zone". Are there some (like this "date" field) that should have remained "without time zone"?
The date field and the archived_date field should be timestamp with time zone in spite of there being a separate timezone field.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 9/18/23 11:19 AM, bryan.kartzman@yu.edu wrote:
And they do have the same thread_id as well:
select a.id, b.starting_email_id, a.message_id_hash, b.thread_id from hyperkitty_email a,hyperkitty_thread b where a.message_id_hash = b.thread_id and a.id = b.starting_email_id and a.id in (1365,1366) ;
id | starting_email_id | message_id_hash | thread_id ------+-------------------+----------------------------------+---------------------------------- 1365 | 1365 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7 1366 | 1366 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7 | UB4WSRNRTPBH7XB6RF3W42U2MUDK77S7 (2 rows)
This is interesting. There are two entries in the hyperkitty_email table
for the same message. Are the other fields, particularly content, for
these ids in the hyperkitty_email table the same?
If so, I'd be inclined to
delete from hyperkitty_email where id = 1366;
delete from hyperkitty_thread where starting_email_id = 1366;
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Its the same message because the professor sent the message to both class lists (the "To:" line): From: David Shatz <shatz@yu.edu> To: 202309-30660@lists.yu.edu;202309-31494@lists.yu.edu
I don't mind deleting the message from the archives of both classes if its way to get rid of this problem quickly. I was thinking of deleting the entire archive for each of those two classes if necessary so this would be less destructive. Is this all I have to do to delete the messages?
delete from hyperkitty_email where id = 1366; delete from hyperkitty_thread where starting_email_id = 1366; delete from hyperkitty_email where id = 1365; delete from hyperkitty_thread where starting_email_id = 1365;
There is nothing else in the database that is dependent on these records?
On 9/18/23 4:44 PM, bryan.kartzman@yu.edu wrote:
Its the same message because the professor sent the message to both class lists (the "To:" line):
Given that this is a cross post and assuming that hyperkitty_email.mailinglist_id is different between the two posts, I don't think this is the issue. I'd have to study the code more than I have to understand exactly what is being looked up by these keys that doesn't exist.
Normally, the thread_order_depth job is run yearly, not minutely. Perhaps it is django-q that's re-running this job every minute. You might consider deleting this task. See https://django-q.readthedocs.io/en/latest/admin.html
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I tried to decypher that page but without much luck.
In the end, I did delete the records from the database (I had to remove records from other tables as well due to foreign key constraints):
postgres=# delete from hyperkitty_lastview where thread_id in ( 1309,1310); postgres=# delete from hyperkitty_attachment where email_id in (1365,1366); postgres=# update hyperkitty_thread set starting_email_id = NULL where starting_email_id in ( 1365,1366); postgres=# delete from hyperkitty_email where id in ( 1365, 1366); postgres=# delete from hyperkitty_thread where id in ( 1309,1310);
And now the error messages have stopped.
The first time I restarted mailman3-web I got two warning messages: WARNING 2023-09-18 21:54:34,850 1825 hyperkitty.tasks Cannot rebuild the thread cache: thread 1310 does not exist. WARNING 2023-09-18 21:54:34,852 1826 hyperkitty.tasks Cannot rebuild the thread cache: thread 1309 does not exist.
Is that something that is going to come back to bite me? Subsequent restarts did not produce the same warning messages.
participants (2)
-
bryan.kartzman＠yu.edu -
Mark Sapiro