> I am aware of pgpool-II and its features. Just that my requirements
> are little different. I have a System (PG runs on it) which already
> has Failover mechanism to another System and I want PG to be part of
> this cluster and not clustered on its own. Mean, PG has to be running
> in Master sys
On Wed, Jan 18, 2012 at 10:54 AM, Manoj Govindassamy
wrote:
> I am aware of pgpool-II and its features. Just that my requirements are
> little different. I have a System (PG runs on it) which already has
> Failover mechanism to another System and I want PG to be part of this
> cluster and not clu
I am aware of pgpool-II and its features. Just that my requirements are
little different. I have a System (PG runs on it) which already has
Failover mechanism to another System and I want PG to be part of this
cluster and not clustered on its own. Mean, PG has to be running in
Master system an
On Wed, Jan 18, 2012 at 6:37 AM, Manoj Govindassamy
wrote:
> (2) We are not comfortable moving to PGPool just for automatic failback mode
> on hot-standby failure.
Hmm.. my reply might be misleading. What I meant was to use pgpool-II
as a clusterware for PostgreSQL built-in replication, not as a
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 mech
On Tue, Jan 17, 2012 at 3:51 AM, Manoj Govindassamy
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
>>> st
