Re: pg_wal folder high disk usage
Paul Brindusa <paulbrindusa88@gmail.com>
From: Paul Brindusa <paulbrindusa88@gmail.com>
To: Koen De Groote <kdg.dev@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Date: 2024-11-04T11:53:41Z
Lists: pgsql-general
Good morning Koen, Highly appreciate your response on this. This has clarified a little bit on the WAL files. Your insights made the whole thing a little bit more clear. Kind Regards, Paul B. On 03/11/2024 13:59, Koen De Groote wrote: > A possible reason for pg_wal buildup is that there is a sort of > replication going on(logical or physical replication) and the > receiving side of the replication has stopped somehow. > > This means: a different server that has a connection to your server > and is expecting to receive data. And your server is then expecting to > have to send data(this is the important bit). There could be multiple > of these connections. > > If even 1 of these receiving servers is down, or the network is out, > or there is some other reason that it is no longer requesting data > from your server, your server will notice it isn't getting > confirmation from that other side, that they have received the data. > As such, your postgres server will keep this data locally, expecting > this situation to be solved in the future, and at that point in time, > send all the data the other side hasn't gotten yet. > > This is 1 option. As long as your server is configured to expect that > other server to be there, and to be receiving, the buildup will > continue. Taking the other server offline won't help, in fact it is > likely the cause of the issue. The official documentation explains how > to get rid of replication slots, ideally your DBA should handle this. > > Laurenz's blogpost lays out all the options, for instance it can also > happen that your system is generating data so fast, the writing of the > WAL files cannot keep up. Or your setup also does WAL archiving and > the compression on that is slow. > > The post offers some ways to verify things, I suggest checking them out. > > And of course, if your DBA is back, have them look at it too. > > Regards, > Koen De Groote > > > On Fri, Nov 1, 2024 at 2:10 PM Greg Sabino Mullane > <htamfids@gmail.com> wrote: > > On Fri, Nov 1, 2024 at 2:40 AM Muhammad Usman Khan > <usman.k@bitnine.net> wrote: > > For immediate space, move older files from pg_Wal to another > storage but don't delete them. > > > No, do not do this! Figure out why WAL is not getting removed by > Postgres and let it do its job once fixed. Please recall the > original poster is trying to figure out what to do because they > are not the database admin, so having them figure out which WAL > are "older" and safe to move is not good advice. > > Resizing the disk is a better option. Could also see if there are > other large files on that volume that can be removed or moved > elsewhere, esp. large log files. > > Hopefully all of this is moot because their DBA is back from > leave. :) > > Cheers, > Greg > >