Skip site navigation (1) Skip section navigation (2)

Re: Postgresql 9.1 replication failing

From: Jerry Sievers <gsievers19(at)comcast(dot)net>
To: Jim Buttafuoco <jim(at)contacttelecom(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgresql 9.1 replication failing
Date: 2011-12-01 19:02:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jim Buttafuoco <jim(at)contacttelecom(dot)com> writes:

> All,
> I have a large PG 9.1.1 server (over 1TB of data) and replica using log shipping.  I had some hardware issues on the
> replica system and now I am getting the following in my pg_log/* files.  Same 2 lines over and over since yesterday.
> 2011-12-01 07:46:30 EST  >LOG:  restored log file "000000010000028E000000E5" from archive
> 2011-12-01 07:46:30 EST  >LOG:  incorrect resource manager data checksum in record at 28E/E555E1B8
> Anything I can do on the replica or do I have to start over?

INspect that WAL segment or possibly the one immediatly following it
in comparison to another copy if you still have it on the master or a
central WAL repository.

A standby crashing meanwhile copying in a WAL segment and/or synching
one to disk could result in ramdon corruption.

If you have another copy of the segment and does not compare equal to
the one your standby is trying to read, try another copy.

> Finally, I know this is not the correct list, I tried general with no answer.

The admin list is the right one for such a post probably.


> Thanks
> Jim
> ___________________________________________________________
> [cid]
> Jim Buttafuoco
> jim(at)contacttelecom(dot)com
> 603-647-7170 ext. 2222- Office
> 603-490-3409 - Cell
> jimbuttafuoco - Skype

Jerry Sievers
Postgres DBA/Development Consulting
e: postgres(dot)consulting(at)comcast(dot)net
p: 305.321.1144

In response to


pgsql-hackers by date

Next:From: Jim ButtafuocoDate: 2011-12-01 19:09:04
Subject: Re: Postgresql 9.1 replication failing
Previous:From: Robert HaasDate: 2011-12-01 18:59:49
Subject: Re: Postgresql 9.1 replication failing

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group