Thread: Standby Mode
The restartableRecovery patch introduces the concept of standby_mode, where you define in the recovery.conf file that this server is acting as a log-shipping target. We can extend that concept to a few other useful places. We've discussed a number of times that we can use a script that waits indefinitely for a log file. On reflection, it seems fairly trivial to put this directly into the backend. I've got a number of possible designs: 1. standby_mode tests to see if restore_command fails, if so it will test for a notification_file then loops back round for the restore_command again. When a failover occurs the failure-sensing mechanism writes the notification file and we bring up the standby. 2. standby_timeout - potentially usable in conjunction with archive_timeout. The standby server loops while waiting for the restore_command to work until it gets to standby_timeout seconds, then automatically comes up in standby mode. Sounds great, but possibly slightly less useful since there's no explicit instruction to perform failover. Both of those are very easy to implement, now that I've seen how, and would augment the other functionality recently delivered for 8.2. What does the panel think? Take the red pill, or stick with blue? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Seems you completed most of the PITR items. That will make great additions for 8.2. --------------------------------------------------------------------------- Simon Riggs wrote: > The restartableRecovery patch introduces the concept of standby_mode, > where you define in the recovery.conf file that this server is acting as > a log-shipping target. We can extend that concept to a few other useful > places. > > We've discussed a number of times that we can use a script that waits > indefinitely for a log file. On reflection, it seems fairly trivial to > put this directly into the backend. I've got a number of possible > designs: > > 1. standby_mode tests to see if restore_command fails, if so it will > test for a notification_file then loops back round for the > restore_command again. When a failover occurs the failure-sensing > mechanism writes the notification file and we bring up the standby. > > 2. standby_timeout - potentially usable in conjunction with > archive_timeout. The standby server loops while waiting for the > restore_command to work until it gets to standby_timeout seconds, then > automatically comes up in standby mode. Sounds great, but possibly > slightly less useful since there's no explicit instruction to perform > failover. > > Both of those are very easy to implement, now that I've seen how, and > would augment the other functionality recently delivered for 8.2. > > What does the panel think? Take the red pill, or stick with blue? > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Mon, 2006-07-31 at 20:34 -0400, Bruce Momjian wrote: > Seems you completed most of the PITR items. That will make great > additions for 8.2. Diogo's xlogviewer stuff should be ready shortly also (1-3 weeks). Since that's a contrib module how do we stand on having that get into 8.2, even though it isn't going to hit the main feature freeze? I'll be able to spend more time with him on that now. Do we care whether that's part of the release or not? It's a pretty specific tool. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Simon Riggs wrote: > On Mon, 2006-07-31 at 20:34 -0400, Bruce Momjian wrote: > > Seems you completed most of the PITR items. That will make great > > additions for 8.2. > > Diogo's xlogviewer stuff should be ready shortly also (1-3 weeks). Since > that's a contrib module how do we stand on having that get into 8.2, > even though it isn't going to hit the main feature freeze? I think we would allow a /contrib tool during freeze, especially since it is a debugging tool and not something that you use for queries. > I'll be able to spend more time with him on that now. > > Do we care whether that's part of the release or not? It's a pretty > specific tool. True. We could put it on pgfoundry and let him make improvements to it during the 8.2 cycle (faster than we can), and then roll it into 8.3. One idea is to put the URL of the pgfoundry project in our documentation. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Simon, > Diogo's xlogviewer stuff should be ready shortly also (1-3 weeks). Since > that's a contrib module how do we stand on having that get into 8.2, > even though it isn't going to hit the main feature freeze? This is why I was asking for status reports on pgsql-students 10 days ago. I guess the question is, will it be *production-ready* in 3 weeks, or just ready to be tested? -- Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus wrote: > Simon, > > > Diogo's xlogviewer stuff should be ready shortly also (1-3 weeks). Since > > that's a contrib module how do we stand on having that get into 8.2, > > even though it isn't going to hit the main feature freeze? > > This is why I was asking for status reports on pgsql-students 10 days ago. > > I guess the question is, will it be *production-ready* in 3 weeks, or just > ready to be tested? At this point we are making no promises that it will be in 8.2. It is possible if we like it in the future, and see no downside, but at this point, just assume it will not be in 8.2. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Josh Berkus <josh@agliodbs.com> writes:
>> Diogo's xlogviewer stuff should be ready shortly also (1-3 weeks). Since
>> that's a contrib module how do we stand on having that get into 8.2,
>> even though it isn't going to hit the main feature freeze?
> This is why I was asking for status reports on pgsql-students 10 days ago.
We've never had a policy of "12:00 AM is the deadline, 1:00 AM is too
late". However, a week or two late is getting towards too late. The
entire point of the feature-freeze deadline is to push the pghackers
community out of "develop cool stuff" mode, and into "fix what you
broke, and how about some documentation and regression tests?" mode.
The train is leaving the station, real soon.
regards, tom lane
Simon, How close do your PITR patches take us to Oracle's "Standby Databases"? I'm trying to decide whether it's a "major features" for PR purposes or not. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On Wed, 2006-08-02 at 13:05 -0700, Josh Berkus wrote: > How close do your PITR patches take us to Oracle's "Standby Databases"? > I'm trying to decide whether it's a "major features" for PR purposes or > not. That was pretty much the sweet spot I was aiming at. Many databases support such functionality. Oracle supports five gradations of functionality, of which we hit first two. There is a sixth level also, which we can hit using Hannu's ideas but thats a roll-your own for now. It would be fair to say that we may support Standby Databases with asynchronous log file shipping. [I have an outstanding question on how to include LWlock support into the archiver, required to flesh out the feature set, and of course assuming these patches being accepted.] -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Simon Riggs <simon@2ndquadrant.com> writes:
> [I have an outstanding question on how to include LWlock support into
> the archiver, required to flesh out the feature set, and of course
> assuming these patches being accepted.]
The archiver is deliberately designed not to be connected to shared
memory. If you want to change that you'll have to make a very strong
case why we should give up the safety and security advantages of it.
regards, tom lane
On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > [I have an outstanding question on how to include LWlock support into > > the archiver, required to flesh out the feature set, and of course > > assuming these patches being accepted.] > > The archiver is deliberately designed not to be connected to shared > memory. If you want to change that you'll have to make a very strong > case why we should give up the safety and security advantages of it. We should let the user decide. If archiver_timeout is a server start GUC then we can attach to shared memory if it is set, if not we avoid that. If they are in a position to want that functionality they can make that trade-off. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Simon Riggs <simon@2ndquadrant.com> writes:
> On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote:
>> The archiver is deliberately designed not to be connected to shared
>> memory. If you want to change that you'll have to make a very strong
>> case why we should give up the safety and security advantages of it.
> We should let the user decide.
Really? The way we let the user decide whether to run as root or not?
I don't think we make security-related decisions that way.
You haven't actually explained what you want this for, so the entire
discussion is operating in a vacuum ...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Simon Riggs <simon@2ndquadrant.com> writes: >> On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote: >>> The archiver is deliberately designed not to be connected to shared >>> memory. If you want to change that you'll have to make a very strong >>> case why we should give up the safety and security advantages of it. > >> We should let the user decide. > > Really? The way we let the user decide whether to run as root or not? > I don't think we make security-related decisions that way. Well there is also precedent the other way, namely fsync. I think the key factor is, is it a decision the user may know more about than we do. In the case of fsync the user may well know that the data isn't important (yet) such as in the case of an initial database load. In general I would say security decisions are more prone rather than less to having this property. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com