f the WAL.
i'd like some unequivocal indication that the WAL was corrupted.
thanks.
From: Jeff Davis
To: Jameison Martin
Cc: "pgsql-general@postgresql.org"
Sent: Wednesday, March 14, 2012 3:55 PM
Subject: Re: [GENERAL] xlog corruption
On Mon,
d to work out the
mechanics of bringing the slave back up to sync with the master and adding it
back to the replica set, which would clearly require some additional machinery.
i hope that clears it up.
thanks.
From: Adrian Klaver
To: Jameison Martin
Cc: "
master.
Thanks.
From: Adrian Klaver
To: pgsql-general@postgresql.org; Jameison Martin
Sent: Monday, February 27, 2012 5:52 PM
Subject: Re: [GENERAL] synchronous replication: blocking commit on the master
On Monday, February 27, 2012 4:36:26 pm Jameison Martin wrote:
> I ha
I'd like to get some clarification around an architectural point about
recovery. I see that it is normal to see "unexpected pageaddr" errors during
recovery because of the way Postgres overwrites old log files, and thus this is
taken to be a normal termination condition, i.e. the end of the log
I have observed that a commit on a replication master hangs if there are no
slaves to communicate with if synchronous replication is enabled. I believe I
have seen a posting that this behavior is deliberate.
In my environment I'd prefer to have the master continue processing
transactions if the
I'm seeing "GMTERROR: canceling autovacuum task" lines in my logs.
2012-02-27 23:53:28 GMTLOG: checkpoint starting: time
>2012-02-27 23:53:31 GMTERROR: canceling autovacuum task
>2012-02-27 23:53:31 GMTCONTEXT: automatic vacuum of table
>".pg_toast.pg_toast_33254"
>2012-02-27 23:53:32 GMTERRO
