Re: Trying to handle db corruption 9.6

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Bimal <internetuser2008(at)yahoo(dot)com>
Cc: Greg Clough <Greg(dot)Clough(at)ihsmarkit(dot)com>, Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Trying to handle db corruption 9.6
Date: 2019-05-20 20:55:53
Message-ID: 20190520205553.f5fst3zleabczf7t@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-performance

On Mon, May 20, 2019 at 04:20:45PM +0000, Bimal wrote:
> I had ran into same issue about year back, luckily I had standby to
> quickly promote. But, I wish there was better a documentation on how to
> handle WAL log fill up and resetting them.

pg_resetxlog is not a tool to deal with "WAL fill up". It's a last
resort option to deal with corrupted WAL, and can easily make matters
worse when used without due consideration. That seems to be the case
here, unfortunately.

On a properly behaving system, running out of disk space for pg_xlog
results in database shutdown. If you also get corrupted WAL, you have
bigger problems, I'm afraid.

Also, data corruption issues are one-off events, mostly unique. That
makes it rather difficult (~impossible) to write docs about recovering
from them. And it's why there are no magic tools.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tomas Vondra 2019-05-20 21:04:06 Re: Trying to handle db corruption 9.6
Previous Message Mariel Cherkassky 2019-05-20 17:20:33 Re: Trying to handle db corruption 9.6

Browse pgsql-performance by date

  From Date Subject
Next Message Tomas Vondra 2019-05-20 21:04:06 Re: Trying to handle db corruption 9.6
Previous Message Jeremy Altavilla 2019-05-20 20:19:48 Re: Analyze results in more expensive query plan