Thread: 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 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? 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 server > > > That'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