2

I have a customer who is trying to set up bidirectional replication with logical replication publication/subcription model across two instances with the help of last_update_wins and reported that with little to no activity he is running out of space. He only have a 5 GB disk as of now with his POC out of which ~2 GB is occupied by wal files (no big fluctuation with the usage) however from the Host console I see that there pg_commit_ts folder keeps growing and is currently @1.7 GB

2.4G    pg_wal
1.7G    pg_commit_ts
96M     db/base
44M     /pg_xact

From postgres documentation I see that this is Subdirectory containing transaction commit timestamp data. I then noticed that he also have enabled "track_commit_timestamp" which collects commit time of transactions.

I'm trying to figure out 1. Is there any way to control retention on pg_commit_ts 2. Is this normal to have huge "pg_commit_ts" with the parameter enabled or does this have to do with their use case.

Please advise.

  • Hard to say what is going on here, since pg_commit_ts does not exist in version 9.3. – jjanes Jun 4 at 20:32
  • came to find out, that unless the XIDs are cleared by vacuum / autovacuum pg_commit_ts would not be cleared. – Ramya Jun 5 at 0:55
2

came to find out, that unless the XIDs are cleared by vacuum / autovacuum pg_commit_ts would not be cleared. So basically this instance needs attention on tuning autovacuum parameters to run autovacuum efficiently

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.