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
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'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
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
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: "
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,