Skip site navigation (1) Skip section navigation (2)

Re: WAL archiving is stuck on an old file that was deleted -- how to get it going again? (8.4.2)

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Aleksey Tsalolikhin <atsaloli(dot)tech(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: WAL archiving is stuck on an old file that was deleted -- how to get it going again? (8.4.2)
Date: 2010-01-07 04:52:50
Message-ID: 3f0b79eb1001062052wfe5c016wf378f41ee014174b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-general
On Thu, Jan 7, 2010 at 11:29 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Aleksey Tsalolikhin escribió:
>
>> I do have a cron job that cleans files older than 2 days out of the
>> pg_xlog directory;
>
> Bad, bad idea.  Get rid of that.  Perfect way to corrupt your system.
> Postgres removes pg_xlog files automatically when they are no longer
> necessary.  If it doesn't remove them, something is happening and you
> need to fix *that*.  Deleting files by hand only works around the
> wasted-disk-space symptom in a bad way.

Completely agreed.

>> How do I get Postgres to stop trying to rsync
>> 00000001000000350000006E, and to do rsync all the WAL files that ARE
>> there?
>
> You're screwed.  You need to get a new base backup; all the files
> you have archived previous to 00000001000000350000006E are useless.
>
> You can get out of the problem by creating a dummy file with that name
> in pg_xlog, but keep in mind that the archive is now completely useless
> and unrecoverable.

Or remove pg_xlog/archive_status/00000001000000350000006E.ready instead
of creating a dummy file. Postgres tries to archive the WAL files whose
.ready file exists in archive_status directory.

And, note that you must get out of the archiving problem *before* making
a new base backup because pg_stop_backup() waits until the last WAL file
filled during backup has been archived. Otherwise, pg_stop_backup() would
get stuck.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

pgsql-general by date

Next:From: Yan Cheng CheokDate: 2010-01-07 05:17:47
Subject: Re: PostgreSQL Write Performance
Previous:From: Guy RouillierDate: 2010-01-07 04:52:19
Subject: Re: FM format modifier does not remove leading zero from year

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group