Re: Parameter name standby_mode - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Parameter name standby_mode
Date
Msg-id m2r5oqhijb.fsf@hi-media.com
Whole thread Raw
In response to Re: Parameter name standby_mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> There's yet another mode that would be useful with hot standby: start up
> the standby, but don't poll the archive and don't try to connect to the
> master. Kind of 'paused' mode. Simon had functions to do that and more
> in the original hot standby patch.

And having the pause/resume functions would lower the need for perfect
conflict resolution too. When you want to run this huge reporting query
set and not get interrupted, pause the standby. Afterward, resume it.

Of course, while paused, it's not a good HA standby anymore, but you
just did pause it, so you're not surprised, right?

> I've been thinking that this would work with just the three options we
> have now:

I like that, because it exposes exactly the code logic, and it is not
complex enough to merit being hidden from the users. Also, you depend on
understanding how the server really works to setup a trustworthy HA
solution, so exposing the very used concepts is a win.

> primary_conninfo (string) specifies a connection string to use to
> connect to the master. If not given, don't try to connect.

Would it be possible to expose that at the SQL level, so that you can
easily check in scripts what master you're a slave of? Think nagios
cascading alerts or topology graphs, etc.

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Streaming Replication docs
Next
From: Fujii Masao
Date:
Subject: Re: TCP keepalive support for libpq