Обсуждение: aggregate + view + alias crash on 7.4 stable

Hi,

A problem related with view was reported from a user. I narrowed down
the problem and found it was related to some usage of views:
(note that with/without limit is not relevant)

test=# select count(a.*) from pg_indexes a limit 10;
server closed the connection unexpectedlyThis probably means the server terminated abnormallybefore or while processing
therequest.
 
The connection to the server was lost. Attempting reset: Failed.
!> 

Here is a backtrace on 7.4-stable and Linux:

Program received signal SIGSEGV, Segmentation fault.
bms_is_empty (a=0x10) at bitmapset.c:519
519             nwords = a->nwords;

(gdb) where
#0  bms_is_empty (a=0x10) at bitmapset.c:519
#1  0x08124fc1 in add_vars_to_targetlist (root=0x82cffc0, vars=0x82ebf20,    where_needed=0x82ebf38) at
initsplan.c:149
#2  0x08124f70 in build_base_rel_tlists (root=0x82cffc0, final_tlist=0x82ebec0)   at initsplan.c:122
#3  0x08125cc5 in query_planner (root=0x82cffc0, tlist=0x82ebec0,    tuple_fraction=0, cheapest_path=0xbfffe428,
sorted_path=0xbfffe42c)  at planmain.c:134
 
#4  0x081268cf in grouping_planner (parse=0x82cffc0, tuple_fraction=10)   at planner.c:895
#5  0x081260f9 in subquery_planner (parse=0x82cffc0, tuple_fraction=0)   at planner.c:315
#6  0x08125e70 in planner (parse=0x82cffc0, isCursor=0, cursorOptions=0)   at planner.c:119
#7  0x081525df in pg_plan_query (querytree=0x82cffc0) at postgres.c:589
#8  0x08152668 in pg_plan_queries (querytrees=0x82ebd68, needSnapshot=0 '\000')   at postgres.c:656
#9  0x08152868 in exec_simple_query (   query_string=0x82cfa38 "select count(a.*) from pg_indexes a limit 10;")   at
postgres.c:814
#10 0x08154ba9 in PostgresMain (argc=4, argv=0x8285ca8,    username=0x8285c78 "t-ishii") at postgres.c:2868
#11 0x0813463d in BackendFork (port=0x8292ee0) at postmaster.c:2558
---Type <return> to continue, or q <return> to quit---
#12 0x08133ed5 in BackendStartup (port=0x8292ee0) at postmaster.c:2201
#13 0x08132838 in ServerLoop () at postmaster.c:1113
#14 0x081323a0 in PostmasterMain (argc=3, argv=0x8283ef0) at postmaster.c:891
#15 0x08108d3f in main (argc=3, argv=0xbffff5c4) at main.c:214
#16 0x400f113f in __libc_start_main (main=0x8108b70 <main>, argc=3,    ubp_av=0xbffff5c4, init=0x806e458 <_init>,
fini=0x81c1760<_fini>,    rtld_fini=0x4000c770 <_dl_fini>, stack_end=0xbffff5bc)   at
../sysdeps/generic/libc-start.c:129

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> test=# select count(a.*) from pg_indexes a limit 10;
> server closed the connection unexpectedly

Hmmm ... the crash is certainly UnGood, but is there any reason we
should accept this query rather than generating an error?  I don't
think it's legal vanilla SQL --- the argument of count() should be
either "*" or a scalar expression per the spec.  I don't know what
it means for the argument of count() to be "foo.*".
        regards, tom lane

> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > test=# select count(a.*) from pg_indexes a limit 10;
> > server closed the connection unexpectedly
> 
> Hmmm ... the crash is certainly UnGood, but is there any reason we
> should accept this query rather than generating an error?  I don't
> think it's legal vanilla SQL --- the argument of count() should be
> either "*" or a scalar expression per the spec.  I don't know what
> it means for the argument of count() to be "foo.*".

If the SQL is not legal, generating an error is enough, I think.
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>>> test=# select count(a.*) from pg_indexes a limit 10;
>>> server closed the connection unexpectedly
>> 
>> Hmmm ... the crash is certainly UnGood, but is there any reason we
>> should accept this query rather than generating an error?

> If the SQL is not legal, generating an error is enough, I think.

The actual bug turns out to affect any use of a whole-row reference to
a subquery, so it has to be fixed whether you think the above is
particularly meaningful or not --- for example, if foo() is defined to
accept a parameter that is the rowtype of pg_indexes, it surely should
work to sayselect foo(a.*) from pg_indexes a;

In light of that, I just fixed the bug and did not do anything about
prohibiting passing rowtype values to count().  We have historically
allowed that, and I haven't got a good argument for removing it.
        regards, tom lane