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 unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
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 unexpectedlyHmmm ... 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 unexpectedlyHmmm ... 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 say
select 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