fix: reach the log-retention job into _supabase over dblink

the supabase image pins cron.database_name to postgres, so pg_cron refuses
jobs scheduled from _supabase, where the log tables live; 1.3.2's upgrade
failed on the first live run with 'can only create extension in database
postgres'. The job now runs in postgres and deletes the _analytics
log_events_* rows in _supabase over a local dblink connection, which needs
no password because the image trusts local connections for supabase_admin.
version 1.3.3

README.md

@@ -1,6 +1,6 @@
 # supaspin
 
-Version 1.3.2
+Version 1.3.3
 
 Create, list, show and delete throwaway [Supabase](https://supabase.com) instances on a
 single-node [microk8s](https://microk8s.io) server, from a terminal menu.
@@ -291,8 +291,10 @@ it receives in the `_supabase` database and never deletes them, so the 2 GB db i
 every delivery with an error, and vector was killed against its 1024 MiB ceiling every few
 minutes with the undeliverable backlog. The fix is log retention: every instance gets a pg_cron
 job (set up on create, upgrade and resume) that deletes analytics logs older than **2 days** every
-night. That bounds both the db image and vector's backlog, so vector is back to the 512 MiB
-ceiling the production supabase charts carry.
+night. pg_cron in this image only runs jobs from the `postgres` database, so the job lives there
+and reaches the log tables in `_supabase` over a local dblink connection. That bounds both the
+db image and vector's backlog, so vector is back to the 512 MiB ceiling the production supabase
+charts carry.
 
 Changing the numbers in this table only affects instances created afterwards. To put them on
 instances that already run, use `sudo supaspin upgrade`: it reads back the values Helm stored when