Pruning remote posts not working #436

Closed
opened 2023-01-13 20:53:49 +00:00 by OctoFloofy · 5 comments

I don't know if i just do something wrong or if it's an actual bug, but pruning remote posts just results in this error

I don't know if i just do something wrong or if it's an actual bug, but pruning remote posts just results in this error

your screenshot contains no errors and shows the command working as expected

your screenshot contains no errors and shows the command working as expected
Author

your screenshot contains no errors and shows the command working as expected

isnt it supposed to delete the remote posts though? cause i can access everything still just fine like before and storage usage didnt decrease.

> your screenshot contains no errors and shows the command working as expected isnt it supposed to delete the remote posts though? cause i can access everything still just fine like before and storage usage didnt decrease.

it deletes objects, not posts

if you view a post again, the system will refetch it

your instance likely isn't old enough for it to have any noticable storage decrease, especially with a query that short

you can check COUNT(id) over objects if you want to be sure it's working (it will be)

it deletes _objects_, not posts if you view a post again, the system will refetch it your instance likely isn't old enough for it to have any noticable storage decrease, especially with a query that short you can check `COUNT(id)` over `objects` if you want to be sure it's working (it will be)

yeah your instance is about a week old, you will be deleting kilobytes at most

yeah your instance is about a week old, you will be deleting kilobytes at most
Contributor

Just fyi because I see that you use vacuum full. If you plan to run this on a regular basis, you shouldn't use the --vacuum option by default. That's more an option for older instances who just start pruning for the first time and therefor will delete a lot of rows. It's better to enable auto vacuum on your database. (This should probably be explained better in the Akkoma docs.)

See the Postgresql docs at https://www.postgresql.org/docs/current/sql-vacuum.html

We recommend that all databases be vacuumed regularly in order to remove dead rows. PostgreSQL includes an “autovacuum” facility which can automate routine vacuum maintenance. For more information about automatic and manual vacuuming, see Section 25.1.

The FULL option is not recommended
for routine use, but might be useful in special cases. An example is
when you have deleted or updated most of the rows in a table and would
like the table to physically shrink to occupy less disk space and allow
faster table scans. VACUUM FULL will usually shrink the table more than a plain VACUUM would.

Just fyi because I see that you use vacuum full. If you plan to run this on a regular basis, you shouldn't use the --vacuum option by default. That's more an option for older instances who just start pruning for the first time and therefor will delete a lot of rows. It's better to enable auto vacuum on your database. (This should probably be explained better in the Akkoma docs.) See the Postgresql docs at <https://www.postgresql.org/docs/current/sql-vacuum.html> > We recommend that all databases be vacuumed regularly in order to remove dead rows. PostgreSQL includes an “autovacuum” facility which can automate routine vacuum maintenance. For more information about automatic and manual vacuuming, see Section 25.1. > The FULL option is not recommended for routine use, but might be useful in special cases. An example is when you have deleted or updated most of the rows in a table and would like the table to physically shrink to occupy less disk space and allow faster table scans. VACUUM FULL will usually shrink the table more than a plain VACUUM would.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#436
No description provided.