From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: standbycheck was:(Re: [HACKERS] testing hot standby |
Date: | 2010-04-26 07:32:59 |
Message-ID: | 4BD541AB.6090600@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jaime Casanova wrote:
> On Wed, Apr 14, 2010 at 9:16 AM, Jaime Casanova
> <jcasanov(at)systemguards(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-04-26 07:43:09 | Re: testing HS/SR - 1 vs 2 performance |
Previous Message | Simon Riggs | 2010-04-26 07:21:35 | Re: testing HS/SR - 1 vs 2 performance |