On 4 November 2016 at 11:20, Gionatan Danti wrote:
> Unfortuntaly I am working with incredible constrains from customer side;
> even buying two SAS disks seems a problem. Moreover, as an external
> consultant, I have basically no decision/buying power :|
> What I can do (and I did) is to raise a v
On 11/04/2016 03:20 AM, Gionatan Danti wrote:
On 03/11/2016 14:20, Adrian Klaver wrote:
The above does not make sense. You are having to recover because there
was no backup and now you want to go forward without doing a backup?
Hi Adrian, no, I don't want go forward without backups ;)
Actu
On 03/11/2016 14:20, Adrian Klaver wrote:
The above does not make sense. You are having to recover because there
was no backup and now you want to go forward without doing a backup?
Hi Adrian, no, I don't want go forward without backups ;)
Actually, the *first* thing I did after the vacuum
On 11/02/2016 11:18 PM, Gionatan Danti wrote:
Il 03-11-2016 00:21 Jim Nasby ha scritto:
On 11/2/16 2:02 PM, Gionatan Danti wrote:
That means at least some of the Postgres files have been damaged
(possibly due to the failing disk). Postgres will complain when it
sees internal data structures tha
Il 03-11-2016 00:21 Jim Nasby ha scritto:
On 11/2/16 2:02 PM, Gionatan Danti wrote:
That means at least some of the Postgres files have been damaged
(possibly due to the failing disk). Postgres will complain when it
sees internal data structures that don't make sense, but it has no way
to know i
On 11/2/16 6:21 PM, Jim Nasby wrote:
I wouldn't trust the existing cluster that far. Since it sounds like you
have no better options, you could use zero_damaged_pages to allow a
pg_dumpall to complete, but you're going to end up with missing data. So
what I'd suggest would be:
stop Postgres
make
On 11/2/16 2:02 PM, Gionatan Danti wrote:
However, backup continue to fail with "invalid page header in block"
message. Morever, I am very near the xid wraparound limit and, as vacuum
fails due to the invalid blocks, I expect a database shutdown (triggered
by the 1M transaction protection) within
Dear all,
some days ago I was tasked to recover a production database from a
failing single-disk (!) system. I initially planned to restore from
backups but, due to the bad disk, backups (done via pg_dumpall) were
failing and nobody cared to notice (!!). Bottom line, the system was
failing and
