Re: WAL & ready files retained after turning off log shipping

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
Cc: PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: Re: WAL & ready files retained after turning off log shipping
Date: 2017-09-13 00:50:23
Message-ID: CAB7nPqT9=gDwYuYCk1tPWMxZddLj6EF2ZV4TRJAS_rqNwavCnA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Sep 12, 2017 at 11:43 PM, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> wrote:
> On 09/07/2017 09:32 AM, Tom Lane wrote:
>>
>> Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Hung Phan 2017-09-13 03:41:43 pg_rewind copy so much data
Previous Message Eric Hanson 2017-09-12 22:21:50 Re: Aquameta 0.1 - Request for reviews, contributors