i guess logical, caused by whatever. i really cannot say, the wal files all
*look* ok, still, they lead to a situation that's a definite dead end.
we did have a hard-drive failure (one in 13) at the time, but due to raid5
+ hot spare no data should have been corrupted. i mean it's an lsi
controller
On Tue, Jul 30, 2013 at 8:18 AM, Klaus Ita wrote:
>
> thank you! It turned out that really there was a corruption in the main pg
> server which was 'virally' propagated to
>
> 1. streaming replica
> 1. replaying wal receiver
> 1. old backup that tried to replay the wal's
>
> I really thought with
Yes, that's it!
thank you! It turned out that really there was a corruption in the main pg
server which was 'virally' propagated to
1. streaming replica
1. replaying wal receiver
1. old backup that tried to replay the wal's
I really thought with a master and 3 backups i'd be safe.
lg,k
On T
On Mon, Jul 29, 2013 at 11:50 PM, Klaus Ita wrote:
> I am trying to remember, there was a tool that plotted the contents of the
> wal_files in a more readable format ...
>
xlogdump?
https://github.com/snaga/xlogdump
Hi!
Thank you, I actually tried that and it seems that only lead to even more
corrupted data. I am currently trying to recover the 'hot-standby' host
that is also unhappy about one of the wal_files. I am looking at the wal
with less and see only data i do not care about in it (mostly
session-loggi
On Tue, Jul 30, 2013 at 4:07 AM, Klaus Ita wrote:
> Sorry for cross-posting, i read that pg-bug was not the right place for
> this email
>
> Hi list!
>
> depressed me gets error messages like these:
>
> 2013-07-29 20:57:09 UTC ERROR: could not access
> status of transaction 8393477
> 2013-07-29
Sorry for cross-posting, i read that pg-bug was not the right place for
this email
Hi list!
depressed me gets error messages like these:
2013-07-29 20:57:09 UTC ERROR: could not access
status of transaction 8393477
2013-07-29 20:57:09 UTC DETAIL: Could not open
file "pg_clog/0008": No such f
