On 02/17/2017 12:34 PM, Richard Brosnahan wrote:
> Thanks for the response Adrian,
>
> Both servers are pretty much identical.
>
> uname -a
> master
> Linux devtmbm178 2.6.32-642.6.2.el6.x86_64 #1 SMP Tue Oct 25 13:37:48
> PDT 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> slave
> Linux devtmbm176 2.6.32-642.11.1.el6.x86_64 #1 SMP Tue Nov 15 09:40:59
> PST 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> Since the last message, I've downgraded PostgreSQL to 9.4.1 on the
> slave, using
> rpm -Uvh --oldpackage [file names]
>
> I had wisely kept copies of the rpm files for PostgreSQL 9.4.1 for OEL6
> and used those. rpm did the downgrade without issue, and I tested the
> 9.4.1 PostgreSQL installation. The minimal testing I did after the
> install worked fine. initdb, start the server, psql, etc.
>
> I then stopped the new slave PostgreSQL instance, and proceeded with the
> instructions for creating a slave.
> I again used pg_basebackup
>
> postgres $ pg_basebackup -D /var/lib/pgsql/9.4/data
> --write-recovery-conf -h devtmbm178.unix.gsm1900.org -U pgrepuser -p 5432 -W
>
>
> NOTICE: pg_stop_backup complete, all required WAL segments have been
> archived
>
>
> This executed without incident.
>
>
> After verifying, and modifying postgresql.conf, recovery.conf I
> attempted to start postgresql. This was again, not successful.
>
>
> postgres $ pg_ctl start
>
> server starting
>
> -bash-4.1$ < 2017-02-17 12:13:53.176 PST >FATAL: incorrect checksum in
> control file
>
>
> postgres $ pg_controldata
>
> WARNING: Calculated CRC checksum does not match value stored in file.
>
> Either the file is corrupt, or it has a different layout than this program
>
> is expecting. The results below are untrustworthy.
>
>
> Segmentation fault (core dumped)
>
>
> Now I'm really unhappy. Same server architecture, same PostgreSQL
> versions. No joy!
Well something is different about the two Postgres instances. I have
lost track of where they came from, but can you parse out the compile
options to each. Suspicion is one is compiled with:
https://www.postgresql.org/docs/9.4/static/install-procedure.html
--disable-integer-datetimes
and one is not, which is the default. You can usually use pg_controldata
to find that:
Date/time type storage: 64-bit integers
Can you use pg_controldata or is it still seg faulting?
If not that then some other compile option.
Just had another thought.
Is there more then one version of Postgres installed on the slave server?
>
>
>
> --
>
> Richard Brosnahan
--
Adrian Klaver
adrian.klaver@aklaver.com
