Thread: hot_standby = on
The docs don't seem to contain any discussion I could find on why one might not want hot_standby on. Maybe it's just too obvious to most people, but this seems to be a bit lacking in the docs. cheers andrew
On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan <andrew.dunstan@pgexperts.com> wrote: > The docs don't seem to contain any discussion I could find on why one might > not want hot_standby on. Maybe it's just too obvious to most people, but > this seems to be a bit lacking in the docs. Well, if you don't want your slave to process queries, then you wouldn't turn it on, presumably. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas wrote: > On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan > <andrew.dunstan@pgexperts.com> wrote: > >> The docs don't seem to contain any discussion I could find on why one might >> not want hot_standby on. Maybe it's just too obvious to most people, but >> this seems to be a bit lacking in the docs. >> > > Well, if you don't want your slave to process queries, then you > wouldn't turn it on, presumably. > > Well, yes. But then to stop that you could just lock users out using pg_hba.conf, no? It just doesn't seem to be buying all that much to me. It's not a big deal, I was just curious. There are all these new knobs to play with ... cheers andrew
On Tue, Jun 8, 2010 at 4:54 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > Robert Haas wrote: >> On Thu, Jun 3, 2010 at 11:15 PM, Andrew Dunstan >> <andrew.dunstan@pgexperts.com> wrote: >>> The docs don't seem to contain any discussion I could find on why one >>> might >>> not want hot_standby on. Maybe it's just too obvious to most people, but >>> this seems to be a bit lacking in the docs. >> Well, if you don't want your slave to process queries, then you >> wouldn't turn it on, presumably. > > Well, yes. But then to stop that you could just lock users out using > pg_hba.conf, no? It just doesn't seem to be buying all that much to me. It's > not a big deal, I was just curious. There are all these new knobs to play > with ... Well, yeah, you could do it that way, too, but that might not be convenient - consider a failover setup where clients try to connect to each IP in turn. You want the standby to refuse connections until it becomes the master, but then start accepting them. I'm going to remove this from the list of open items for 9.0 since, as you say, it's not a big deal. :-) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Andrew Dunstan <andrew@dunslane.net> writes:
> Well, yes. But then to stop that you could just lock users out using
> pg_hba.conf, no? It just doesn't seem to be buying all that much to me.
The main reason to turn it off is to disable a whole lot of very poorly
tested code, and thereby improve the reliability of your warm standby
server. There might be (almost certainly are) significant performance
benefits as well. I think it'll be at least a couple of release cycles
before any sane DBA would turn it on on standbys where he didn't
positively need it.
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Well, yes. But then to stop that you could just lock users out using >> pg_hba.conf, no? It just doesn't seem to be buying all that much to me. >> > > The main reason to turn it off is to disable a whole lot of very poorly > tested code, and thereby improve the reliability of your warm standby > server. There might be (almost certainly are) significant performance > benefits as well. I think it'll be at least a couple of release cycles > before any sane DBA would turn it on on standbys where he didn't > positively need it. > > > OK, then we need to say something like that. Right now we're not giving any guidance that I can see. cheers andrew
On Tue, 2010-06-08 at 17:24 -0400, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > Well, yes. But then to stop that you could just lock users out using > > pg_hba.conf, no? It just doesn't seem to be buying all that much to me. > > The main reason to turn it off is to disable a whole lot of very poorly > tested code, and thereby improve the reliability of your warm standby > server. > There might be (almost certainly are) significant performance > benefits as well. I would be happy to look over any performance results you have that show this to be true. I only know of one area I thought was a significant loss in some cases, which you canned because we had no evidence it was a problem... -- Simon Riggs www.2ndQuadrant.com