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

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: (view raw, whole thread or download thread mbox)
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


pgsql-admin by date

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

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