Re: starting postgres with an empty px_xlog folder

From: Mike Broers <mbroers(at)gmail(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: starting postgres with an empty px_xlog folder
Date: 2012-06-25 14:45:25
Message-ID: CAB9893gYG8mpwoLPe+pQ2CdhNv5GETyveLvb8_FErK+rH_g2CQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Ultimately the hosting service restored the files that they had not brought
over during their maintenance migration and we started up ok. So that was
a relief.

We had archived log files but it did not appear that the archive
destination was caught up with the xlog the cluster was complaining about.

Given that the database server was shut down cleanly, and all other data
besides pg_xlog was available as expected (not corrupted), what would have
been the problem with pg_resetxlogs?

On Sun, Jun 24, 2012 at 2:15 AM, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> wrote:

> On 06/24/2012 03:45 AM, Kevin Grittner wrote:
>
>> As previously stated, make sure you understand how this happened, so
>> you can make sure it doesn't happen again. The contents of the
>> pg_xlog directory are an integral part of your database cluster.
>>
>
> People not backing up pg_xlog, deleting its contents, etc happens often
> enough that I wonder if it should have a prominent 00_README or
> 00_WARNING_DONT_DELETE file created by initdb - or simply be renamed to
> something scarier like "base_txrecords".
>
> The annoyance of a readme is that it'd need translation.
>
> People are used to logs being disposable. Anyone who's been responsible
> for a database should ideally know better than to assume that *transation*
> logs are disposable, but everyone has to learn sometime, and not everybody
> does so by reading TFM (unfortunately).
>
> --
> Craig Ringer
>

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Radovan Jablonovsky 2012-06-25 15:00:46 Re: terminating autovacuum process due to administrator command
Previous Message Kevin Grittner 2012-06-25 10:56:42 Re: a very slow SQL