public inbox for [email protected]
help / color / mirror / Atom feedFrom: Paul Brindusa <[email protected]>
To: Koen De Groote <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: pg_wal folder high disk usage
Date: Mon, 4 Nov 2024 11:53:41 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAGbX52E+rimrOsVW4r4Jn_brwGGVfw3qs2hipAoffcCYGfmexg@mail.gmail.com>
References: <CAFeSbqjySUzp_Q4XNR_ajnV84O=om0f5rzpjPsQaNitDkxXjHw@mail.gmail.com>
<CAPnRvGuJ5oxEJ1xmJ2ULU63VNCKMcpbvkU-vO9wEdehA2KyZRw@mail.gmail.com>
<CAKAnmmJwRQekE-4bGAmVEoP9KQdLtWz9+=CzBYGa_11KTbeQ2g@mail.gmail.com>
<CAGbX52E+rimrOsVW4r4Jn_brwGGVfw3qs2hipAoffcCYGfmexg@mail.gmail.com>
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
> <[email protected]> wrote:
>
> On Fri, Nov 1, 2024 at 2:40 AM Muhammad Usman Khan
> <[email protected]> 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
>
>
view thread (3+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: pg_wal folder high disk usage
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox