Prev: pgsql: Make standby server continuously retry restoringthe next WAL
Next: pg_restore --single-transaction and --clean
From: Heikki Linnakangas on 10 Feb 2010 06:16
Joachim Wieland wrote:
> We want to teach people that Hot Standby and Streaming Replication are
> two different features.

I'm not sure about that, actually. Now that they're both in the tree,
they work nicely together and many users will think of them as one.

> However, Streaming Replication calls its main
> parameter "standby_mode" which reminds more of Hot Standby than of
> Streaming Replication.
>
> People could also run a warm standby without streaming replication,
> which would result in a standby that has standby_mode = 'off'.

If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.

If you want to use pg_standby or similar tools, then you would indeed
set standby_mode='off', but I think that makes sense because you're
implementing the standby functionality outside the server in that case.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Joachim Wieland on 10 Feb 2010 13:10
On Wed, Feb 10, 2010 at 12:16 PM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> If they want to implement the warm standby using the (new) built-in
> logic to keep retrying restore_command, they would set
> standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
>
> If you want to use pg_standby or similar tools, then you would indeed
> set standby_mode='off', but I think that makes sense because you're
> implementing the standby functionality outside the server in that case.

Okay, got it now with your explanations.

For some reason it didn't work before with standby_mode = 'on' (it
does now) and the warning "FATAL: sorry, too many standbys already"
gave me a first suspicion that SR is the only use case for this. Then
I checked the docs and there it said "If this parameter is on, the
streaming replication is enabled". I understand now what it does and
that it is a prerequisite but that there is also a non-SR use case...
So the name is okay for me :-)


Thanks again,
Joachim

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 12 Feb 2010 02:59
Joachim Wieland wrote:
> On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
>> Yeah, even if primary_conninfo is not given, the standby tries to invoke
>> walreceiver by using the another connection settings (environment variables
>> or defaults). This is intentional behavior, and would make the setup of SR
>> easier. So I'd like to leave it be.
>
> On the other hand, if it has to use defaults for the target host/port,
> chances are high that either it connects to the wrong host/port or
> that SR is just not wanted :-)

Agreed. I've changed it now so that if primary_conninfo is not set, it
doesn't try to establish a streaming connection. If you want to get the
connection information from environment variables, you can use
primary_conninfo=''.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Fujii Masao on 12 Feb 2010 03:23
On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> Agreed. I've changed it now so that if primary_conninfo is not set, it
> doesn't try to establish a streaming connection. If you want to get the
> connection information from environment variables, you can use
> primary_conninfo=''.

OK, you win. I would live with primary_conninfo=''.

And you need to change the document, recovery.conf.sample and
so on.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Joachim Wieland on 12 Feb 2010 04:11
On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> Agreed. I've changed it now so that if primary_conninfo is not set, it
> doesn't try to establish a streaming connection. If you want to get the
> connection information from environment variables, you can use
> primary_conninfo=''.

Why not just remove the default:

If no primary_conninfo variable is set explicitly in the configuration
file, check the environment variables. If the environment variable is
not set, don't try to establish a connection.

?

Joachim

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: pgsql: Make standby server continuously retry restoringthe next WAL
Next: pg_restore --single-transaction and --clean