Prev: [HACKERS] improve plpgsql's EXECUTE 'select into' message with a hint
Next: recovery_connections cannot start
From: Jaime Casanova on 26 Apr 2010 02:49
On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
<jcasanov(a)systemguards.com.ec> wrote:
> On Sat, Apr 10, 2010 at 12:23 AM, Jaime Casanova
> <jcasanov(a)systemguards.com.ec> wrote:
>> On Fri, Apr 9, 2010 at 3:39 PM, Jaime Casanova
>> <jcasanov(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 26 Apr 2010 03:32
Jaime Casanova wrote:
> On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
> <jcasanov(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Jaime Casanova on 26 Apr 2010 03:45
On Mon, Apr 26, 2010 at 2:32 AM, Heikki Linnakangas
<heikki.linnakangas(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on 1 May 2010 08:22
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(a)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


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Jaime Casanova on 1 May 2010 10:05
On Sat, May 1, 2010 at 7:22 AM, Simon Riggs <simon(a)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(a)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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3
Prev: [HACKERS] improve plpgsql's EXECUTE 'select into' message with a hint
Next: recovery_connections cannot start