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
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 |
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 |