Thank you for your insight Seenu!
That is a good point, unfortunately we do not have access to the server/file system as the database is a managed service.
Access to the file system from postgres like pg_ls_dir is also blocked.
Are you aware of another, creative way to infer the wal file size from within postgres?
Best Regards
Chris
On Tue, Aug 4, 2020 at 11:39 AM Srinivasa T N <seenutn@xxxxxxxxx> wrote:
There may be lot of wal files or the size of log files in pg_log might be huge. "du -sh *" of data directory holding the database might help.Regards,Seenu.On Tue, Aug 4, 2020 at 2:09 PM Chris Borckholder <chris.borckholder@xxxxxxxxxxxx> wrote:Hi!We are experiencing a strange situation with an AWS Aurora postgres instance.The database steadily grows in size, which is expected and normal.After enabling logical replication, the disk usage reported by AWS metrics increases much faster then the database size (as seen by \l+ in psql). The current state is that database size is ~290GB, while AWS reports >640GB disk usage.We reached out to AWS support of course, which is ultimately responsible.Unfortunately they were not able to diagnose this until now.I checked with the queries from wiki https://wiki.postgresql.org/wiki/Disk_Usage , which essentially give the same result.I tried to check on wal segment file size, but we have no permission to execute select pg_ls_waldir().The replication slot is active and it also progresses (pg_replication_slots.confirmed_flush_lsn increases and is close to pg_current_wal_flush_lsn).Can you imagine other things that I could check from within postgres with limited permissions to diagnose this?Best RegardsChris
