SEO

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

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. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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. +

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly