Обсуждение: Re: [HACKERS] CURRENT: crash in select_view regression test...

Hi,

I think I need some help here

Taking part of the pg_views rule shows it thinks the views
are NOT views.
postgres=> SELECT relname AS viewname, pg_get_userbyid(relowner) AS viewowner,  
pg_get_viewdef(relname) AS definition  FROM pg_class WHERE relhasrules;
viewname  |viewowner|definition
----------+---------+----------
pg_user   |postgres |Not a view
pg_rules  |postgres |Not a view
pg_views  |postgres |Not a view
pg_tables |postgres |Not a view
pg_indexes|postgres |Not a view
(5 rows)

If I select from the view I get a BE crash.


postgres=> select * from pg_views;
pqReadData() -- backend closed the channel unexpectedly.       This probably means the backend terminated abnormally
beforeor while processing the 
 
request.
We have lost the connection to the backend, so further processing is impossible.  Terminating.        


Here's the backtrace...

Program received signal SIGSEGV, Segmentation fault.
0xbcd64 in ApplyRetrieveRule (parsetree=0x1f0790, rule=0xefffaf20, rt_index=1, relation_level=1,   relation=0x1f0690,
modified=0xefffaf1c)at rewriteHandler.c:1817
 
1817            rtable = nconc(rtable, copyObject(rule_action->rtable));
(gdb) bt
#0  0xbcd64 in ApplyRetrieveRule (parsetree=0x1f0790, rule=0xefffaf20, rt_index=1, 
relation_level=1,   relation=0x1f0690, modified=0xefffaf1c) at rewriteHandler.c:1817
#1  0xbd250 in fireRIRrules (parsetree=0x1f0790) at rewriteHandler.c:2079
#2  0xbd950 in QueryRewrite (parsetree=0x198a50) at rewriteHandler.c:2615
#3  0xceeb4 in pg_parse_and_plan (query_string=0xefffd1a0 "select * from pg_views;", typev=0x0, 
nargs=0,   queryListP=0xefffd094, dest=Remote, aclOverride=0 '\000') at postgres.c:505
#4  0xcf290 in pg_exec_query_dest (query_string=0xefffd1a0 "select * from pg_views;", 
dest=Remote,   aclOverride=0 '\000') at postgres.c:722
#5  0xcf244 in pg_exec_query (query_string=0xefffd1a0 "select * from pg_views;") at 
postgres.c:699
#6  0xd0588 in PostgresMain (argc=-8192, argv=0x15dc00, real_argc=10, real_argv=0xeffffd84) at 
postgres.c:1646
#7  0xb2fd4 in DoBackend (port=0x135800) at postmaster.c:1532
#8  0xb2a60 in BackendStartup (port=0x199c00) at postmaster.c:1303
#9  0xb1ec8 in ServerLoop () at postmaster.c:757
#10 0xb1a10 in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:563
#11 0x83f14 in main (argc=10, argv=0xeffffd84) at main.c:93           

If I start looking around in ruleutils.c why can't I see "spirc"??

Breakpoint 2, pg_get_viewdef (rname=0xe01d56a0) at ruleutils.c:277
277             if (spirc != SPI_OK_SELECT)
(gdb) print spirc
No symbol "spirc" in current context.
(gdb) list
272             args[1] = PointerGetDatum(name2);
273             nulls[0] = ' ';
274             nulls[1] = ' ';
275             nulls[2] = '\0';
276             spirc = SPI_execp(plan_getview, args, nulls, 1);
277             if (spirc != SPI_OK_SELECT)
278                     elog(ERROR, "failed to get pg_rewrite tuple for view %s", rulename);
279             if (SPI_processed != 1)
280                     tmp = "Not a view";
281             else                                           

Jan in particular, any idea what's happening here?

Keith.



Keith Parks <emkxp01@mtcc.demon.co.uk>
> Appologies,
> 
> It looks like this was not the fix, as I'm still getting the
> Bad node message....
> 
> 
> Will continue investigating.
> 
> Keith.
> 
> Keith Parks <emkxp01@mtcc.demon.co.uk>
> > 
> > Vadim Mikheev <vadim@krs.ru>
> > > 
> > > Keith Parks wrote:
> > > > 
> > > > Vadim Mikheev <vadim@krs.ru>
> > > > >
> > > > > ... in SELECT * FROM street;
> > > > >
> > > > 
> > > > No crash just:-
> > > > 
> > > > regression=> select * from street;
> > > > ERROR:  nodeRead: Bad type 0
> > > > regression=>
> > > 
> > > It seems platform dependent...
> > > Bugs are in readfuncs.c
> > > 
> > 
> > I think I've found it, a simple typo in outfuncs.c.
> > 
> > Looks like :vartypmod got transmuted to %vartypmod in an editing session.
> > 
> > Here's the patch,
> > 
> > Keith.
> > 
> > *** src/backend/nodes/outfuncs.c.orig   Thu Dec 17 12:01:02 1998
> > --- src/backend/nodes/outfuncs.c        Thu Dec 17 12:01:22 1998
> > ***************
> > *** 634,640 ****
> >   _outVar(StringInfo str, Var *node)
> >   {
> >         appendStringInfo(str,
> > !                       " VAR :varno %d :varattno %d :vartype %u %vartypmod %d ",
> >                         node->varno,
> >                         node->varattno,
> >                         node->vartype,
> > --- 634,640 ----
> >   _outVar(StringInfo str, Var *node)
> >   {
> >         appendStringInfo(str,
> > !                       " VAR :varno %d :varattno %d :vartype %u :vartypmod %d ",
> >                         node->varno,
> >                         node->varattno,
> >                         node->vartype,    
> > 
> > 
> 

fwiw, I was mucking around in the rules/views part of the code recently,
adding support for the CASE construct. I didn't fully understand the
areas I was modifying, but the changes shouldn't be visible if you
aren't dealing with the new construct. At least that was my
impression...

How long have you been seeing problems? It looks like I made changes on
Dec 14. But all regression tests passed on my system at that time with
my source tree, which had some of Vadim's changes already.
                    - Tom

"Thomas G. Lockhart" wrote:
> 
> fwiw, I was mucking around in the rules/views part of the code recently,
> adding support for the CASE construct. I didn't fully understand the
> areas I was modifying, but the changes shouldn't be visible if you
> aren't dealing with the new construct. At least that was my
> impression...
> 
> How long have you been seeing problems? It looks like I made changes on
> Dec 14. But all regression tests passed on my system at that time with
> my source tree, which had some of Vadim's changes already.

I don't remember. Problems are in readfuncs/outfuncs area...

BTW, right now I get:

vac=> select * from test where x = 1;
ERROR:  type id lookup of 0 failed

- from parser...
I'm trying to fix it now...

Vadim

Vadim Mikheev wrote:
> 
> BTW, right now I get:
> 
> vac=> select * from test where x = 1;
> ERROR:  type id lookup of 0 failed
> 
> - from parser...
> I'm trying to fix it now...

Ops, sorry - I had to gmake clean in parser dir after
adding SET TRANSACTION ISOLATION LEVEL...

Vadim

> If I select from the view I get a BE crash.

    That was a typo in nodes/read.c that is fixed.

> If I start looking around in ruleutils.c why can't I see "spirc"??
>
> Breakpoint 2, pg_get_viewdef (rname=0xe01d56a0) at ruleutils.c:277
> 277             if (spirc != SPI_OK_SELECT)
> (gdb) print spirc
> No symbol "spirc" in current context.
> (gdb) list
> 272             args[1] = PointerGetDatum(name2);
> 273             nulls[0] = ' ';
> 274             nulls[1] = ' ';
> 275             nulls[2] = '\0';
> 276             spirc = SPI_execp(plan_getview, args, nulls, 1);
> 277             if (spirc != SPI_OK_SELECT)
> 278                     elog(ERROR, "failed to get pg_rewrite tuple for view %s", rulename);
> 279             if (SPI_processed != 1)
> 280                     tmp = "Not a view";
> 281             else
>
> Jan in particular, any idea what's happening here?

    Must take a look at it anyway. Thomas added new node types
    which must be handled there too (CASE).


Jan

--

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

>     Must take a look at it anyway. Thomas added new node types
>     which must be handled there too (CASE).

Well, while you are looking... :)

I've enclosed case.sql, which is closer to a complete test of the CASE
statement. There are a few queries which are commented out because they
crash the backend on my machine. If you happen to see why, that would be
great.

The crashing statements involve multiple tables. afaik single-table
queries work pretty well.

I haven't given up on looking for the problem, but was giving my eyes a
few days rest before getting back to it.

                       - Tom--
-- case.sql
--
-- Test the case statement
--

--
-- Clean up
--

DROP TABLE CASE_TBL;
DROP TABLE CASE2_TBL;

CREATE TABLE CASE_TBL (
  i integer,
  f double precision
);

CREATE TABLE CASE2_TBL (
  i integer,
  j integer
);

INSERT INTO CASE_TBL VALUES (1, 10.1);
INSERT INTO CASE_TBL VALUES (2, 20.2);
INSERT INTO CASE_TBL VALUES (3, -30.3);
INSERT INTO CASE_TBL VALUES (4, NULL);

INSERT INTO CASE2_TBL VALUES (1, -1);
INSERT INTO CASE2_TBL VALUES (2, -2);
INSERT INTO CASE2_TBL VALUES (3, -3);
INSERT INTO CASE2_TBL VALUES (2, -4);
INSERT INTO CASE2_TBL VALUES (1, NULL);
INSERT INTO CASE2_TBL VALUES (NULL, -6);

--
-- Simplest examples without tables
--

SELECT '3' AS "One",
  CASE
    WHEN 1 < 2 THEN 3
  END AS "Simple WHEN";

SELECT '<NULL>' AS "One",
  CASE
    WHEN 1 > 2 THEN 3
  END AS "Simple default";

SELECT '3' AS "One",
  CASE
    WHEN 1 < 2 THEN 3
    ELSE 4
  END AS "Simple ELSE";

SELECT '4' AS "One",
  CASE
    WHEN 1 > 2 THEN 3
    ELSE 4
  END AS "ELSE default";

SELECT '6' AS "One",
  CASE
    WHEN 1 > 2 THEN 3
    WHEN 4 < 5 THEN 6
    ELSE 7
  END AS "Two WHEN with default";

--
-- Examples of targets involving tables
--

SELECT '' AS "Five",
  CASE
    WHEN i >= 0 THEN i
  END AS ">= 0 or Null"
  FROM CASE_TBL;

SELECT '' AS "Five",
  CASE WHEN i >= 0 THEN (i - i)
       ELSE i
  END AS "Simplest Math"
  FROM CASE_TBL;

SELECT '' AS "Five", i AS "Value",
  CASE WHEN (i < 0) THEN 'small'
       WHEN (i = 0) THEN 'zero'
       WHEN (i = 1) THEN 'one'
       WHEN (i = 2) THEN 'two'
       ELSE 'big'
  END AS "Category"
  FROM CASE_TBL;

/*
SELECT '' AS "Five",
  CASE WHEN ((i < 0) or (i < 0)) THEN 'small'
       WHEN ((i = 0) or (i = 0)) THEN 'zero'
       WHEN ((i = 1) or (i = 1)) THEN 'one'
       WHEN ((i = 2) or (i = 2)) THEN 'two'
       ELSE 'big'
  END AS "Category"
  FROM CASE_TBL;
*/

--
-- Examples of qualifications involving tables
--

--
-- NULLIF() and COALESCE()
-- Shorthand forms for typical CASE constructs
--  defined in the SQL92 standard.
--

SELECT * FROM CASE_TBL WHERE COALESCE(f,i) = 4;

SELECT * FROM CASE_TBL WHERE NULLIF(f,i) = 2;

/*
This crashes the backend at the moment...
- thomas 1998-12-12
SELECT COALESCE(a.i, a.f, b.i, b.j)
  FROM CASE_TBL a, CASE2_TBL b;
*/

SELECT *
  FROM CASE_TBL a, CASE2_TBL b
  WHERE COALESCE(a.i, a.f, b.i, b.j) = 4;

/*
This crashes the backend at the moment...
- thomas 1998-12-12
SELECT '' AS Five, NULLIF(a.i,b.i) AS "NULLIF(a.i,b.i)",
  NULLIF(b.i, 4) AS "NULLIF(b.i,4)"
  FROM CASE_TBL a, CASE2_TBL b;
*/

SELECT '' AS "Two", *
  FROM CASE_TBL a, CASE2_TBL b
  WHERE COALESCE(f,b.i) = 2;

--
-- Examples of updates involving tables
--

UPDATE CASE_TBL
  SET i = CASE WHEN i >= 0 THEN (- i)
                ELSE (2 * i) END;

SELECT * FROM CASE_TBL;

UPDATE CASE_TBL
  SET i = CASE WHEN i >= 2 THEN (2 * i)
                ELSE (3 * i) END;

SELECT * FROM CASE_TBL;

/*
This crashes the backend at the moment...
- thomas 1998-12-12
UPDATE CASE_TBL
  SET i = CASE WHEN b.i >= 2 THEN (2 * j)
                ELSE (3 * j) END
  FROM CASE2_TBL b
  WHERE j = -CASE_TBL.i;

SELECT * FROM CASE_TBL;
*/

> Hi,
> 
> I think I need some help here
> 
> Taking part of the pg_views rule shows it thinks the views
> are NOT views.
>  
> postgres=> SELECT relname AS viewname, pg_get_userbyid(relowner) AS viewowner,  
> pg_get_viewdef(relname) AS definition  FROM pg_class WHERE relhasrules;
> viewname  |viewowner|definition
> ----------+---------+----------
> pg_user   |postgres |Not a view
> pg_rules  |postgres |Not a view
> pg_views  |postgres |Not a view
> pg_tables |postgres |Not a view
> pg_indexes|postgres |Not a view
> (5 rows)

Works in the current development tree.



--  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