Thanks for your views.
(1) Will try out emptying synchronous_standby_names on replica failures
and verify if the transactions proceeds thru.
(2) We are not comfortable moving to PGPool just for automatic failback
mode on hot-standby failure. Any suggestions on how to build this
failback mechanism for master in PG9.1.2 ? We are using C interface for
PG. Any kind of health checking that we can do on the master to detect
the hot-standby problem and let master reload its config with empty
synchronous_standby_names ?
Any help is much appreciated.
thanks,
Manoj
On 01/16/2012 07:44 PM, Fujii Masao wrote:
On Tue, Jan 17, 2012 at 3:51 AM, Manoj Govindassamy
<manoj@xxxxxxxxxxxxxxxxx> wrote:
1. Transaction which was stuck right when slave going away never went
thru even after I reloaded master's config with local commit on. I do see
all new transactions on master are going thru fine, except the one which was
stuck initially. How to get this stuck transaction complete or return with
error.
Changing synchronous_commit doesn't affect such a transaction. Instead,
empty synchronous_standby_names and reload the configuration file to
resume that transaction.
2. Whenever there is a problem with slave, I have to manually reload
master's config with local commit turned on to get master go forward. Is
there any automated way to reload this config with local commit on on
slave's unresponsiveness ? tcp connection timeouts, replication timeouts all
detect the failures, but i want to run some corrective action on these
failure detection.
PostgreSQL doesn't have such a capability, but pgpool-II might have.
Can you ask that in pgpool-II mailing-list?
Regards,
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
