On Tue, Sep 12, 2017 at 11:43 PM, Ron Johnson <ron.l.johnson@xxxxxxx> wrote: > On 09/07/2017 09:32 AM, Tom Lane wrote: >> >> Ron Johnson <ron.l.johnson@xxxxxxx> writes: >>> >>> On 09/07/2017 09:08 AM, Tom Lane wrote: >>>> >>>> Manual cleanup shouldn't be very hard, fortunately. Run pg_controldata >>>> to see where the last checkpoint is, and delete WAL files whose names >>>> indicate they are before that (but not the one including the >>>> checkpoint!). Just noticed. This is actually forgetting that you can only remove safely WAL segment past the last *prior* checkpoint, not the last checkpoint. So you need to keep WAL segments worth of two completed checkpoints. >>> All WAL files after log shipping was stopped will keep accumulating >>> "forever"? >> >> Hmm ... on second thought, I think if you just remove the .ready/.done >> files, the next checkpoint should clean up the old WAL files. That'd >> certainly be safer than doing it manually. > > This weekend, (early Sunday morning) WAL files on the master started > accumulating again. Now, .ready files are regenerated every time I delete > them, even though according to pg_controldate the last checkpoint was 28 > minutes ago. My general advice here would be: do not mess up with the contents of the data folder while Postgres is running, you will never do that right. What is your archiving command telling then? If those .ready files are here, it means that you are not able to archive correctly segments. It seems to me that at the end you should try to just set archive_command = '/bin/true', this would solve all your problems, and trick the server correctly... -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
