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
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 Jablonovsky||Date: 2012-06-25 15:00:46|
|Subject: Re: terminating autovacuum process due to administrator command|
|Previous:||From: Kevin Grittner||Date: 2012-06-25 10:56:42|
|Subject: Re: a very slow SQL|