standbycheck was:(Re: [HACKERS] testing hot standby
On Sat, Apr 10, 2010 at 12:23 AM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:
On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:i think "make standbycheck" needs a little more work, why it isn't
accesible from top of source dir?
what i want to do.
1) make standbycheck should be accesible from top source dirs
2) it should use an existing regression database on an already
configured standby server (no need of the hs_primary_setup.sql)
3) it should execute the existing set of tests (the ones installcheck
execute) but with a new set of expected results, that way we can be
sure that what should be disallowed is disallowed and that the
database is returning consistent values. i've thought about having
expected/normal (or expected/primary) and expected/standby and check
actual results against the appropiate one depending if we use
installcheck and standbycheck
comments? i will start this the weekend...
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:
On Sat, Apr 10, 2010 at 12:23 AM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:i think "make standbycheck" needs a little more work, why it isn't
accesible from top of source dir?what i want to do.
i started to make this, this weekend
3) it should execute the existing set of tests (the ones installcheck
execute) but with a new set of expected results, that way we can be
sure that what should be disallowed is disallowed and that the
database is returning consistent values. i've thought about having
expected/normal (or expected/primary) and expected/standby and check
actual results against the appropiate one depending if we use
installcheck and standbycheck
the real question here is how pg_regress.c should know that it should
compare against expected/primary or expected/standby?
i mean, could i add an --standby option (my preferred) to pg_regress.c
or should i try to guess it from current options and/or asking to the
server?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Jaime Casanova wrote:
On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:3) it should execute the existing set of tests (the ones installcheck
execute) but with a new set of expected results, that way we can be
sure that what should be disallowed is disallowed and that the
database is returning consistent values. i've thought about having
expected/normal (or expected/primary) and expected/standby and check
actual results against the appropiate one depending if we use
installcheck and standbycheckthe real question here is how pg_regress.c should know that it should
compare against expected/primary or expected/standby?
i mean, could i add an --standby option (my preferred) to pg_regress.c
or should i try to guess it from current options and/or asking to the
server?
How many of the tests in the regular regression suite do anything useful
when run against a standby server? They all have to set up a bunch of
objects before they run queries, so you just get a lot of errors
complaining that you can't do X in standby mode, followed by errors
about missing objects. That doesn't sound very useful.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
How many of the tests in the regular regression suite do anything useful
when run against a standby server? They all have to set up a bunch of
objects before they run queries, so you just get a lot of errors
complaining that you can't do X in standby mode, followed by errors
about missing objects. That doesn't sound very useful.
granted. what i'm looking for is a way of continually see that the
standby will return consistent values and yes, i want to be sure that
we disallow everything that we need to...
maybe just a new set of tests? maybe i just should make the hs_* tests
use regression's database tables intead of the ones it is using?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
On Mon, 2010-04-26 at 02:45 -0500, Jaime Casanova wrote:
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:How many of the tests in the regular regression suite do anything useful
when run against a standby server? They all have to set up a bunch of
objects before they run queries, so you just get a lot of errors
complaining that you can't do X in standby mode, followed by errors
about missing objects. That doesn't sound very useful.granted. what i'm looking for is a way of continually see that the
standby will return consistent values and yes, i want to be sure that
we disallow everything that we need to...maybe just a new set of tests? maybe i just should make the hs_* tests
use regression's database tables intead of the ones it is using?
The existing standbycheck does statically test for all the things that
should be allowed and all the things that should be disallowed. If its
missing some, please say.
Standbycheck doesn't test dynamic behaviour, which is more than a
regression test suite is supposed to do. Yes, dynamic tests needed also.
The most important thing now is that there are some tests in CVS and
they cover the documented static behaviours.
--
Simon Riggs www.2ndQuadrant.com
On Sat, May 1, 2010 at 7:22 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Mon, 2010-04-26 at 02:45 -0500, Jaime Casanova wrote:
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:How many of the tests in the regular regression suite do anything useful
when run against a standby server? They all have to set up a bunch of
objects before they run queries, so you just get a lot of errors
complaining that you can't do X in standby mode, followed by errors
about missing objects. That doesn't sound very useful.granted. what i'm looking for is a way of continually see that the
standby will return consistent values and yes, i want to be sure that
we disallow everything that we need to...maybe just a new set of tests? maybe i just should make the hs_* tests
use regression's database tables intead of the ones it is using?The existing standbycheck does statically test for all the things that
should be allowed and all the things that should be disallowed. If its
missing some, please say.
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
regression database to run standbycheck in the standby server
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
regression database to run standbycheck in the standby server
That's part of the procedure already.
We need something better for the future, though not sure if there's any
small tweaks worth making for 9.0 right now. Let's start making wider
plans for next release.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs <simon@2ndQuadrant.com> writes:
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
regression database to run standbycheck in the standby server
That's part of the procedure already.
Where is this test procedure documented?
regards, tom lane
On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
Simon Riggs <simon@2ndQuadrant.com> writes:
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
regression database to run standbycheck in the standby serverThat's part of the procedure already.
Where is this test procedure documented?
In src/test/regress/standby_schedule
hs_standby_check.sql throws warning if not setup correctly.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs <simon@2ndQuadrant.com> writes:
On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
Where is this test procedure documented?
In src/test/regress/standby_schedule
That's a good way to ensure nobody knows it's there :-(
If you want users to run this, document it in cookbook fashion in
doc/src/sgml/regress.sgml
regards, tom lane
On Sat, 2010-05-01 at 13:12 -0400, Tom Lane wrote:
Simon Riggs <simon@2ndQuadrant.com> writes:
On Sat, 2010-05-01 at 12:37 -0400, Tom Lane wrote:
Where is this test procedure documented?
In src/test/regress/standby_schedule
That's a good way to ensure nobody knows it's there :-(
If you want users to run this, document it in cookbook fashion in
doc/src/sgml/regress.sgml
OK
--
Simon Riggs www.2ndQuadrant.com
On Sat, 2010-05-01 at 09:05 -0500, Jaime Casanova wrote:
maybe we should be using the tables that exists in the regression
database or adding hs_setup_primary in installcheck to prepare the
regression database to run standbycheck in the standby server
This can definitely use some improvement though not yet.
I've documented what's there a little better and fixed up the test
results.
Thanks for your input in this area.
--
Simon Riggs www.2ndQuadrant.com