Hi,

    I  know  that  it's  the  new  psql output format why all the
    regression tests currently fail. But I think we are  in  this
    state  for  a  little too long now. With the latest CVS I got
    this near the end of the suite after the plpgsql test:

NOTICE:  trying to delete a reldesc that does not exist.
NOTICE:  trying to delete a reldesc that does not exist.
Server process (pid 12207) exited with status 139 at Wed Nov 17 10:57:36 1999
Terminating any active server processes...
Server processes were terminated at Wed Nov 17 10:57:36 1999
Reinitializing shared memory and semaphores
DEBUG:  Data Base System is starting up at Wed Nov 17 10:57:36 1999

    This indicates that someone made changes  that  really  broke
    something  and since he wasn't able to get any useful results
    from a regression run, he just didn't do it.

    I see a little problem with checking if the output  is  still
    O.K.  too.   It  seems  that  psql  now buffers all the query
    result messages until a SELECT is done. So if the  regression
    input  contains only INSERT/UPDATE/DELETE statements, all the
    responses are at the end, not after each statement.

    It's really a mess. How should  someone  check  if  a  system
    catalog  change  is O.K. in this situation? I intend to do so
    soon!


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Wed, 17 Nov 1999 11:07:48 +0100 (MET)
wieck@debis.com (Jan Wieck)
regression tests
On Wed, 17 Nov 1999, Jan Wieck wrote:

>     I  know  that  it's  the  new  psql output format why all the
>     regression tests currently fail. But I think we are  in  this
>     state  for  a  little too long now. With the latest CVS I got

As I mentioned before: use the old psql for regression tests and/or just
run the regression tests once with the old one and once with the new one
and make those results the new reference. (Maybe I'm oversimplifying here,
though.)

Once again this thought also: How about running the regression tests on a
single user postgres backend directly? That way you don't rely on some
obscure frontend and some client library which might change soon, too.
Also you have more control over internals. Finally, you could easily run
the regression tests on an uninstalled build. Think ./configure; make;
make check; make install. Or am I way out there now?

>     I see a little problem with checking if the output  is  still
>     O.K.  too.   It  seems  that  psql  now buffers all the query
>     result messages until a SELECT is done. So if the  regression
>     input  contains only INSERT/UPDATE/DELETE statements, all the
>     responses are at the end, not after each statement.

Huh? psql doesn't buffer anything. Could you please elaborate on this
and/or give me an example? I never heard of that one and I thought Bruce
was a really thorough tester . . .

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Wed, 17 Nov 1999 12:22:11 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] regression tests
Peter Eisentraut wrote:
>
> Once again this thought also: How about running the regression tests on a
> single user postgres backend directly? That way you don't rely on some
> obscure frontend and some client library which might change soon, too.
> Also you have more control over internals. Finally, you could easily run
> the regression tests on an uninstalled build. Think ./configure; make;
> make check; make install. Or am I way out there now?

    That  should have been done BEFORE messing up anything.  This
    hasn't been done, so I think it's the job of those who change
    output  formats,  to  provide new expected regression results
    too. This hasn't been done too, and that's bad.

>
> >     I see a little problem with checking if the output  is  still
> >     O.K.  too.   It  seems  that  psql  now buffers all the query
> >     result messages until a SELECT is done. So if the  regression
> >     input  contains only INSERT/UPDATE/DELETE statements, all the
> >     responses are at the end, not after each statement.
>
> Huh? psql doesn't buffer anything. Could you please elaborate on this
> and/or give me an example? I never heard of that one and I thought Bruce
> was a really thorough tester . . .

    As I see, the result messages aren't in  the  (old)  expected
    outputs at all. But they are now. From the boolean test:

    CREATE TABLE BOOLTBL1 (f1 bool);

    INSERT INTO BOOLTBL1 (f1) VALUES ('t'::bool);

    INSERT INTO BOOLTBL1 (f1) VALUES ('True'::bool);

    INSERT INTO BOOLTBL1 (f1) VALUES ('true'::bool);

    -- BOOLTBL1 should be full of true's at this point
    SELECT '' AS t_3, BOOLTBL1.*;
    CREATE
    INSERT 18633 1
    INSERT 18634 1
    INSERT 18635 1
     t_3 | f1
    -----+----
         | t
         | t
         | t
    (3 rows)

    As  you  can see, the CREATE and INSERT responses are printed
    after the SELECT statement, just before it's own output.

    Again, if someone changes things that change output,  he  has
    to provide new expected results for the regression suite.  If
    the changes to psql are still a work in progress,  it  should
    have been done on separated sources until at least the output
    format is stable.

    What actually happened isn't good practice  (IMHO).  Ask  all
    other  developers  to work around some temporary misbehaviour
    that makes the entire backend development a blind flight. And
    the  fatal  abnormal  backend  termination  at the end of the
    regression show's what this lazyness can end in. ISTM someone
    has  broken  something and didn't notice. Thus, at least that
    other one didn't do it with your mentioned workaround.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Wed, 17 Nov 1999 12:46:29 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] regression tests
I wrote:

> NOTICE:  trying to delete a reldesc that does not exist.
> NOTICE:  trying to delete a reldesc that does not exist.
> Server process (pid 12207) exited with status 139 at Wed Nov 17 10:57:36 1999
> Terminating any active server processes...
> Server processes were terminated at Wed Nov 17 10:57:36 1999
> Reinitializing shared memory and semaphores
> DEBUG:  Data Base System is starting up at Wed Nov 17 10:57:36 1999
>

    I took Peter Eisentraut's advice and did it with the old pslq
    (thanks for the hint).

    This problem (as expected) remains and happens  in  the  temp
    test.   The  two notices occur on creating the temp table and
    the index on it.  After that, the database  connection  get's
    lost on the attempt to drop the temp table.

    Since the postmaster is doing recovery then, the numeric test
    hasn't been run. All other tests are still O.K.

    The question is, who did  something  that  could  cause  this
    error?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Wed, 17 Nov 1999 13:48:39 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] regression tests
On Wed, 17 Nov 1999, Jan Wieck wrote:

>     That  should have been done BEFORE messing up anything.  This
>     hasn't been done, so I think it's the job of those who change
>     output  formats,  to  provide new expected regression results
>     too. This hasn't been done too, and that's bad.

I explicitly informed everyone that this would happen a long time before I
finalized psql. Nobody seemed to care a lot. Now, weeks after the fact
some people start wondering that perhaps they want to run regression tests
once in a while. I'm not the regression test maintainer, nor do I have
knowledge of how to remake them, so all I can do is inform everyone and
cooperate on anything that's necessary. But silence is implicit approval.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Wed, 17 Nov 1999 14:33:37 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] regression tests
>     I took Peter Eisentraut's advice and did it with the old pslq
>     (thanks for the hint).
> 
>     This problem (as expected) remains and happens  in  the  temp
>     test.   The  two notices occur on creating the temp table and
>     the index on it.  After that, the database  connection  get's
>     lost on the attempt to drop the temp table.
> 
>     Since the postmaster is doing recovery then, the numeric test
>     hasn't been run. All other tests are still O.K.
> 
>     The question is, who did  something  that  could  cause  this
>     error?

I am sure it was me changing the temp behavior.  I will look at it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 17 Nov 1999 10:52:40 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] regression tests
Bruce Momjian wrote:

> >     The question is, who did  something  that  could  cause  this
> >     error?
>
> I am sure it was me changing the temp behavior.  I will look at it.

    Running the queries in question in gdb shows:

backend> CREATE TABLE temptest(col int);
backend> CREATE INDEX i_temptest ON temptest(col);
backend> CREATE TEMP TABLE temptest(col int);
NOTICE:  trying to delete a reldesc that does not exist.
NOTICE:  trying to delete a reldesc that does not exist.
backend> CREATE INDEX i_temptest ON temptest(col);
NOTICE:  trying to delete a reldesc that does not exist.
NOTICE:  trying to delete a reldesc that does not exist.
backend> DROP INDEX i_temptest;
backend> DROP TABLE temptest;

Program received signal SIGSEGV, Segmentation fault.
0x806b47d in heap_openr (relationName=0x81c4e90 "temptest", lockmode=7)
    at heapam.c:569
569             if (RelationIsValid(r) && r->rd_rel->relkind == RELKIND_INDEX)

(gdb) print *r
$2 = {rd_fd = 65536, rd_nblocks = 184, rd_refcnt = 38017,
  rd_myxactonly = 16 '\020', rd_isnailed = 8 '\b', rd_isnoname = 0 '\000',
  rd_unlinked = 0 '\000', rd_am = 0xb8, rd_rel = 0x2, rd_id = 2,
  rd_lockInfo = {lockRelId = {relId = 403, dbId = 131072}}, rd_att = 0xb8,
  rd_rules = 0x8109480, rd_istrat = 0x0, rd_support = 0xb8, trigdesc = 0x2}

    The  problem  at this point is that r->rd_rel is 0x2, causing
    the SIGSEGV.  But I assume the real problem  occured  earlier
    where  the  notice's  came from. The relation descriptor must
    have gotten messed up somehow during the CREATE TEMP TABLE.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #



Wed, 17 Nov 1999 20:37:32 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] regression tests
> Bruce Momjian wrote:
> 
> > >     The question is, who did  something  that  could  cause  this
> > >     error?
> >
> > I am sure it was me changing the temp behavior.  I will look at it.
> 
>     Running the queries in question in gdb shows:
> 
> backend> CREATE TABLE temptest(col int);
> backend> CREATE INDEX i_temptest ON temptest(col);
> backend> CREATE TEMP TABLE temptest(col int);
> NOTICE:  trying to delete a reldesc that does not exist.
> NOTICE:  trying to delete a reldesc that does not exist.
> backend> CREATE INDEX i_temptest ON temptest(col);
> NOTICE:  trying to delete a reldesc that does not exist.
> NOTICE:  trying to delete a reldesc that does not exist.
> backend> DROP INDEX i_temptest;
> backend> DROP TABLE temptest;
> 

Let me try some tests now.   I have an idea.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 17 Nov 1999 15:15:54 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] regression tests
> Bruce Momjian wrote:
> 
> > >     The question is, who did  something  that  could  cause  this
> > >     error?
> >
> > I am sure it was me changing the temp behavior.  I will look at it.
> 
>     Running the queries in question in gdb shows:
> 
> backend> CREATE TABLE temptest(col int);
> backend> CREATE INDEX i_temptest ON temptest(col);
> backend> CREATE TEMP TABLE temptest(col int);
> NOTICE:  trying to delete a reldesc that does not exist.
> NOTICE:  trying to delete a reldesc that does not exist.
> backend> CREATE INDEX i_temptest ON temptest(col);
> NOTICE:  trying to delete a reldesc that does not exist.
> NOTICE:  trying to delete a reldesc that does not exist.
> backend> DROP INDEX i_temptest;
> backend> DROP TABLE temptest;

Sorry.  I see it now.  Let me fix it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 17 Nov 1999 15:56:23 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] regression tests
> > Bruce Momjian wrote:
> > 
> > > >     The question is, who did  something  that  could  cause  this
> > > >     error?
> > >
> > > I am sure it was me changing the temp behavior.  I will look at it.
> > 
> >     Running the queries in question in gdb shows:
> > 
> > backend> CREATE TABLE temptest(col int);
> > backend> CREATE INDEX i_temptest ON temptest(col);
> > backend> CREATE TEMP TABLE temptest(col int);
> > NOTICE:  trying to delete a reldesc that does not exist.
> > NOTICE:  trying to delete a reldesc that does not exist.
> > backend> CREATE INDEX i_temptest ON temptest(col);
> > NOTICE:  trying to delete a reldesc that does not exist.
> > NOTICE:  trying to delete a reldesc that does not exist.
> > backend> DROP INDEX i_temptest;
> > backend> DROP TABLE temptest;
> 
> Sorry.  I see it now.  Let me fix it.

OK, fixed.  Seems there was some confusion in the cache over whether
tables where indexed by logical or phsical names in the hash table to
clear out the cache.  Fixed now.  Sorry.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 17 Nov 1999 18:50:44 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] regression tests