Nathan

> this function site_aggregates_comment_delete - lacks a WHERE clause, if that is running every row on every single delete, that would be a major performance bug impacting routine deletes... Yeah...

I think you copied and pasted the triggers without the extra where?

I used pgdump --schema-only to get my baseline rather than try to make sure I had the latest migration files. I think your file name suggestion is a reasonable assumption....

I just had a realization. If I patch lemmy.ca and one user deleted themselves, is that going to federate out and crash every lemmy instance?

When a user deletes since all their comments are edited and then flagged as deleted, i would assume that will run on all instances. I'm also basing this assumption on...

> I suppose a worst-case situation is that a server tries to federate it, the transaction fails on the receiving server, and then they go into retry battles... No the...

It's in #3649. It's not a big query., just the update.

Read the conditional function used in the trigger. If the deleted column changes from false to true, it's classified as a comment delete. It's not about actually doing a Sql...

Read the code for was_removed_or_deleted() and it'll make more sense. When you delete a comment, lemmy updates every row to overwrite the data and mark it as deleted.

That's not the right trigger definition. ``` CREATE OR REPLACE TRIGGER site_aggregates_comment_delete AFTER DELETE OR UPDATE OF removed, deleted ON public.comment FOR EACH ROW WHEN (old.local = true) EXECUTE FUNCTION...