CURRENT: crash in select_view regression test...

Vadim Mikheev <vadim@krs.ru>

... in SELECT * FROM street;

No crash just:-

regression=> select * from street;
ERROR: nodeRead: Bad type 0
regression=>

Keith.

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

Vadim

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,    

My fault...patch applied...sorry about that :(

On Thu, 17 Dec 1998, Keith Parks wrote:

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,    

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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>

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

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

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, Pennsylvania 19026

Bruce,

This problem with VIEWs was fixed by Jan WiecK on or
around 18th December.

Keith.

Bruce Momjian <maillist@candle.pha.pa.us>

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,