pool timeouts/rich media cherry-picks #796
No reviewers
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#796
Loading…
Reference in a new issue
No description provided.
Delete branch "pool-timeouts"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
seems to be working so far on akko.wtf, memory usage is significantly lower than before
There are two follow up PRs in Pleroma fixing some mistakes in the cherry-picked richmedia refactor:
Seem unrelated to the binary leaks we observed in testing though
Async tasks we love async tasks don't we folks we love memory management it's the best
@ -33,3 +34,1 @@
spawn(fn ->
Pleroma.Web.RichMedia.Helpers.fetch_data_for_activity(activity)
end)
spawn(fn -> Card.get_by_activity(activity) end)
does this spawning still maeks sense now that updates can be streamed if it wasn't cached yet?
nope it does not
especially now that it's just an oban
@ -0,0 +94,4 @@
end
@spec get_by_object(Object.t()) :: t() | nil | :error
def get_by_object(object) do
where is this function used?
Ctr+F
doesn't show anything in the diffyeah seems nowhere
purged
@ -0,0 +10,4 @@
end
create(unique_index(:rich_media_card, [:url_hash]))
end
url_hash
might as well be the primary key here, considering it must be unique, we want fast lookups via it and afaict we don't ever care about the auto-generated numeric primary key.Will save us space and an index for a unused primary key (but needs an extra migration to migrate to/from current Pleroma — ofc if PLeroma migrators are required to rollback to an earlier state before migration, this doesn't matter)
i tried this, because :url_hash is a :bytea type, it cannot be used as a primary key
it seems ecto (and postgres in general) only really wants you to use either fixed-length :binary_id or integer :id fields as primary keys
i'll keep it as is - primary key indices shouldn't really be that much size-wise
Plain PostgreSQL has no issue creating a table with a bytea primary key:
ecto won't allow it though 😩
Did the error only appear at runtime? Compiling and migrating with this works for me™:
Also i only now noticed the migration ID is again out of order, leading to belated rollbacks; an extra table might not matter too much though
ship it (tm)
WIP: pool timeouts/rich media cherry-picksto pool timeouts/rich media cherry-picks