I brought down the master then the slave and upgraded both. Then I did the
rsync and brought both up.. This worked. However with the database being
very large it took quite a while. It seemed rsync had to make a lot of
changes.. this surprised me. I thought they would be almost identical.
But
I have replication set up on servers with 9.1 and want to upgrade to 9.2
I was hoping I could just bring them both down, upgrade them both and bring
them both up and continue replication, but that doesn't seem to work, the
replication server won't come up.
Is there anyway to do this upgrade with ou
Jeff Janes wrote
>
> It seems like it shouldn't be all that hard to write a tool to parse
> WAL logs in a context-free basis (i.e. without the backup to start
> applying them to) and emit some kind of descriptions of the records
> and their sizes. But I don't know about such a tool already exist
Jeff Janes wrote
>
> Maybe there is an easier way, but one thing would be to compile a test
> server (of the same version as the production) with WAL_DEBUG defined
> in src/include/pg_config_manual.h, turn on the wal_debug guc, and
> crank up trace_recovery_messages. Then replay the WAL log file
Josh Berkus wrote
>
>> We are not doing anything to postgres that would cause the rise and
>> drop.
>> Data base activity is pretty consistent. nor are we doing any kind
>> of
>> purge. This week the drop occurred after 6 days. We are thinking it
>> must
>> be some kind of internal postgres ac
We are not doing anything to postgres that would cause the rise and drop.
Data base activity is pretty consistent. nor are we doing any kind of
purge. This week the drop occurred after 6 days. We are thinking it must
be some kind of internal postgres activity but we can't track it down.
--
V
