pg_standby and build farm
I've written up a Warm Standby script as a .c program rather than
scripts, to allow it to be portable and potentially shipped as part of
PostgreSQL core.
pg_standby is designed to be a wait-for restore_command, required to
turn a normal archive recovery into a Warm Standby. Within the
restore_command of the recovery.conf you could configure pg_standby in
the following way:
restore_command = 'pg_standby archiveDir %f %p'
It has a number of other useful options and works with Win32 also.
So far I've written this as a contrib module. Would people like to see
this submitted to -patches, or should I make it available via PgFoundry
HAPITR?
Should this be reworked as an src/bin program? Or is the contrib module
the best form for this in 8.3?
I've also written a test program that uses this. I'm using this on a
server at EDB to run a continuous Warm Standby test.
Would anybody consider this test script worth including somewhere in
core? and/or: Might it become part of the build farm?
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
I'd love to see your program. Could you please submit to -pacthes?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Show quoted text
I've written up a Warm Standby script as a .c program rather than
scripts, to allow it to be portable and potentially shipped as part of
PostgreSQL core.pg_standby is designed to be a wait-for restore_command, required to
turn a normal archive recovery into a Warm Standby. Within the
restore_command of the recovery.conf you could configure pg_standby in
the following way:restore_command = 'pg_standby archiveDir %f %p'
It has a number of other useful options and works with Win32 also.
So far I've written this as a contrib module. Would people like to see
this submitted to -patches, or should I make it available via PgFoundry
HAPITR?Should this be reworked as an src/bin program? Or is the contrib module
the best form for this in 8.3?I've also written a test program that uses this. I'm using this on a
server at EDB to run a continuous Warm Standby test.Would anybody consider this test script worth including somewhere in
core? and/or: Might it become part of the build farm?--
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
Simon Riggs wrote:
I've written up a Warm Standby script as a .c program rather than
scripts, to allow it to be portable and potentially shipped as part of
PostgreSQL core.
Great! It'll make the DBA's work much easier, could help the adoption of
PITR (nowadays people thinks it's to complicate to code a script) and
help Win32 users.
So far I've written this as a contrib module. Would people like to see
this submitted to -patches, or should I make it available via PgFoundry
HAPITR?Should this be reworked as an src/bin program? Or is the contrib module
the best form for this in 8.3?
Please submit it to -patches. IMHO it should stay in src/bin because
it'll be part of a solution that is tightly integrated to core (PITR).
--
Euler Taveira de Oliveira
http://www.timbira.com/
Euler Taveira de Oliveira <euler@timbira.com> writes:
Simon Riggs wrote:
Should this be reworked as an src/bin program? Or is the contrib module
the best form for this in 8.3?Please submit it to -patches. IMHO it should stay in src/bin because
it'll be part of a solution that is tightly integrated to core (PITR).
I think src/bin would be a seriously bad place for it, because that
carries the presumption that "there can be only one", whereas in reality
this will be more like an example of one way to do it. contrib seems OK.
(And no, it should NOT be perceived as "tightly integrated to core".
The entire point of the design is to keep that behavior separate.)
regards, tom lane
Simon Riggs wrote:
I've also written a test program that uses this. I'm using this on a
server at EDB to run a continuous Warm Standby test.Would anybody consider this test script worth including somewhere in
core? and/or: Might it become part of the build farm?
Buildfarm automatically runs all regression tests in core, including in
contrib. Running some other test where the code is in core could be
trivial, as long as there was a boolean success criterion. But of course
it has to run on a single machine.
Send me details and I can take a look.
cheers
andrew
On Wed, 2006-12-13 at 19:43 -0500, Tom Lane wrote:
Euler Taveira de Oliveira <euler@timbira.com> writes:
Simon Riggs wrote:
Should this be reworked as an src/bin program? Or is the contrib module
the best form for this in 8.3?Please submit it to -patches. IMHO it should stay in src/bin because
it'll be part of a solution that is tightly integrated to core (PITR).
Posted to pgsql-patches
I think src/bin would be a seriously bad place for it, because that
carries the presumption that "there can be only one", whereas in reality
this will be more like an example of one way to do it. contrib seems OK.
Agreed.
I will be updating it each time we have feedback on integration with
various BAR systems to provide more options as standard.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
On Thu, 2006-12-14 at 07:35 +0900, Tatsuo Ishii wrote:
Could you please submit to -pacthes?
Patch submitted to -patches as requested last Thursday.
Any feedback would be gratefully received.
Thanks,
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com