Re: MY PATCH - Mailing list pgsql-patches
From | Chris Bitmead |
---|---|
Subject | Re: MY PATCH |
Date | |
Msg-id | 3940D28B.80B20A4E@bitmead.com Whole thread Raw |
Responses |
Re: [CORE] Re: MY PATCH
Re: Re: MY PATCH |
List | pgsql-patches |
The regression results are correct. It's just that they're different than what they used to be because of the SQL3 ONLY incompatibility. I wasn't sure if people wanted to change the regression tests to give the old results, or just insert the new results. Also, I don't get any core dump. Are you sure you did a full clean and initdb? Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > No. I assume the users do that before submitting the patch. > > I can back it out. > > Well, let's brace him about it first. > > Chris, your patch is showing six regression test failures including > a coredump. Please show cause why it shouldn't be reversed out > forthwith. This is not good enough to be applied to CVS, not even > early in a development cycle --- you've just made it impossible for > other developers to tell whether *their* work is OK or not. > > regards, tom lane > > >> Not looking good. Did you not bother to run regression tests > >> before committing? > >> > >> =============== running regression queries... ================= > >> boolean .. ok > >> char .. ok > >> name .. ok > >> varchar .. ok > >> text .. ok > >> int2 .. ok > >> int4 .. ok > >> int8 .. ok > >> oid .. ok > >> float4 .. ok > >> float8 .. ok > >> numeric .. ok > >> strings .. ok > >> numerology .. ok > >> point .. ok > >> lseg .. ok > >> box .. ok > >> path .. ok > >> polygon .. ok > >> circle .. ok > >> interval .. ok > >> timestamp .. ok > >> reltime .. ok > >> tinterval .. ok > >> inet .. ok > >> comments .. ok > >> oidjoins .. ok > >> type_sanity .. ok > >> opr_sanity .. ok > >> abstime .. ok > >> geometry .. ok > >> horology .. ok > >> create_function_1 .. ok > >> create_type .. ok > >> create_table .. ok > >> create_function_2 .. ok > >> copy .. ok > >> constraints .. > >> Pid 17071 received a SIGSEGV for stack growth failure. > >> Possible causes: insufficient memory or swap space, > >> or stack size exceeded maxssiz. > >> failed > >> triggers .. ok > >> create_misc .. ok > >> create_aggregate .. ok > >> create_operator .. ok > >> create_index .. ok > >> inherit .. ./regress.sh[126]: sql/inherit.sql: Cannot find or open the file. > >> diff: expected/inherit.out: No such file or directory > >> diff: results/inherit.out: No such file or directory > >> ok > >> create_view .. ok > >> sanity_check .. ok > >> errors .. ok > >> select .. ok > >> select_into .. ok > >> select_distinct .. ok > >> select_distinct_on .. ok > >> select_implicit .. ok > >> select_having .. ok > >> subselect .. ok > >> union .. ok > >> case .. ok > >> join .. ok > >> aggregates .. failed > >> transactions .. ok > >> random .. ok > >> portals .. ok > >> arrays .. ok > >> btree_index .. ok > >> hash_index .. ok > >> misc .. failed > >> select_views .. failed > >> alter_table .. ok > >> portals_p2 .. ok > >> rules .. failed > >> foreign_key .. ok > >> limit .. ok > >> plpgsql .. ok > >> temp .. ok > >> > >> > >> regards, tom lane > >> > > > -- > > Bruce Momjian | http://www.op.net/~candle > > pgman@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 -- Chris Bitmead mailto:chris@bitmead.com
pgsql-patches by date: