Re: standbycheck was:(Re: [HACKERS] testing hot standby - Mailing list pgsql-hackers

From Jaime Casanova
Subject Re: standbycheck was:(Re: [HACKERS] testing hot standby
Date
Msg-id x2j3073cc9b1004252349r85f9cca5j6c91843f1ed34584@mail.gmail.com
Whole thread Raw
In response to standbycheck was:(Re: [HACKERS] testing hot standby  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Responses Re: standbycheck was:(Re: [HACKERS] testing hot standby  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: improve plpgsql's EXECUTE 'select into' message with a hint
Next
From: Fujii Masao
Date:
Subject: Re: testing HS/SR - 1 vs 2 performance