Thread: regression tests
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) #
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
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) #
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) #
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
> 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, Pennsylvania19026
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) #
> 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, Pennsylvania19026
> 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, Pennsylvania19026
> > 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, Pennsylvania19026