Re: [HACKERS] CURRENT: crash in select_view regression test... - Mailing list pgsql-hackers

From Keith Parks
Subject Re: [HACKERS] CURRENT: crash in select_view regression test...
Date
Msg-id 199812180116.BAA07749@mtcc.demon.co.uk
Whole thread Raw
Responses Re: [HACKERS] CURRENT: crash in select_view regression test...
Re: [HACKERS] CURRENT: crash in select_view regression test...
List pgsql-hackers
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,    
> > 
> > 
> 



pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] redolog - for discussion
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] CVS log for a specific tag