Thanks @TheFlyingCoder, this is very helpful!
Here’s a cleaned-up version of the replication slot output:
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
-----------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
stolon_aad02ae2 | | physical | | | f | f | | | | 9B/B6000060 | | extended | | f
The version of Fly PG that you’re using includes Stolon to manage replication and high availability. It looks like it created a replication slot for some reason, so PG is retaining WAL for a replica that doesn’t exist. (If you created more than one PG instance in this app and subsequently deleted all but one, this might be how it was created.)
Below I’ve added a few suggestions to address this, but remember that this isn’t managed Postgres, so it’s ultimately up to you to decide what to do and to handle any issues that arise.
Before doing anything, I’d suggest verifying (e.g. with fly status) that there really are no replicas in your app, and making sure that you have a recent database backup available just in case.
Then in your logs, do you see no keeper info available messages appearing frequently? If so, Stolon still thinks that a replica exists. You might try following the instructions in this thread (just be very careful when identifying the correct keeper to remove!):
There’s additional info about this here:
If you don’t see any no keeper info available messages, it may be enough to delete the replication slot using this SQL query with fly pg connect:
SELECT pg_drop_replication_slot('stolon_aad02ae2');
Hope this helps!