I think that you need to create a new base backup from the new master to
make the old master a standby server. I usually do this using rsync, so
that it takes as fast as possible, but you could also use a tool like
http://www.repmgr.org/
Regards,
Strahinja
On Mon, May 13, 2013 at 9:23 AM,
I can answer your first question. The way I check the replication delay is
by running this query on the replication server:
*SELECT now() - pg_last_xact_replay_timestamp();*
Of course you need to configure hot standby replication, which you should
if you are not.
Regards,
Strahinja
On Tue,
What does your shell script do that you need a script for archiving? The
archive command is usually a cp/scp/rsync command, you usually don't need
more than that.
Regards,
Strahinja
On Fri, Apr 26, 2013 at 3:55 PM, Albe Laurenz laurenz.a...@wien.gv.atwrote:
German Becker wrote:
Here is the
How can the archive process fall behind? Postgres will never reuse WAL
files which are not yet archived.
Regarding your question about slowing down WAL generation, that is not
possible to do, unless you slow down the application which is doing the
writing into the database.
Regards,
Strahinja
Sorry for a late reply, but I had the exact same problem and it was a bug
in the Red Hat RPM package upgrade script of the sudo package. This
basically means the user running Postgres cannot resolve hostname
localhost. Have you tried logging in as the user running Postgres and
trying to resolve
