Re: pg ignores wal files in pg_wal, and instead tries to load them from archive/primary - Mailing list pgsql-bugs

From Jeff Janes
Subject Re: pg ignores wal files in pg_wal, and instead tries to load them from archive/primary
Date
Msg-id CAMkU=1z2AeiruX-NWxyuMaQXGSXuNUpTaFC1paODkmXYLrMXhw@mail.gmail.com
Whole thread Raw
In response to pg ignores wal files in pg_wal, and instead tries to load them from archive/primary  (hubert depesz lubaczewski <depesz@depesz.com>)
List pgsql-bugs

Currently our goto fix is:
1. increase wal_keep_size to ~ 200GB
2. standaup replica
3. once it catches up decrease wal_keep_size to standard (for us) 16GB

but it is not really nice solution.

If you don't have an archive and aren't using a permanent slot, then you always have the risk of blowing past your available WAL.

Increasing wal_keep_size is an option to reduce this risk.  Yes, it is not so nice, but you have already declined to use the nicer options.

Where those extra unusable files came from is a curiosity, but nothing more than that.  I'm guessing they were created by the wrapper you said you use, as I can't reproduce their existence with just pg_basebackup.  They are probably "recycled ahead" files from the master that somehow got copied needlessly, and with a file name which does not match the file contents (since they contents are from a previous name the file had).  pg_waldump isn't as helpful as it could be in those cases.

Cheers,

Jeff

pgsql-bugs by date:

Previous
From: Shane Plesner
Date:
Subject: Re: Bug / Unintentional Feature: non-immutable functions can be used for generated columns.
Next
From: Tom Lane
Date:
Subject: Re: Bug / Unintentional Feature: non-immutable functions can be used for generated columns.