On Wed, 2016-03-09 at 18:21 +0100, Tomas Vondra wrote: > Hi, > > On Wed, 2016-03-09 at 08:45 -0800, Jeff Janes wrote: > > On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra > > <tomas.von...@2ndquadrant.com> wrote: > > > Hi, > > > > > > thanks for the feedback. Attached is v14 of the patch series, fixing > > > most of the points you've raised. > > > > > > Hi Tomas, > > > > Applied to aa09cd242fa7e3a694a31f, I still get the seg faults in make > > check if I configure without --enable-cassert. > > Ah, after disabling asserts I can reproduce it too. And the reason why > it fails is quite simple - clauselist_selectivity modifies the original > list of clauses, which then confuses cost_qual_eval.
More precisely, it gets confused because the first clause in the list gets deleted but cost_qual_eval never learns about that, and follows stale pointer to the next cell, thus a segfault. > > Can you try if the attached patch fixes the issue? I'll need to rework a > bit more of the code, but let's see if this fixes the issue on your > machine too. > > > With --enable-cassert, it passes the regression test. > > I wonder how can it work with casserts and fail without them. That's > kinda exactly the opposite to what I'd expect ... FWIW it seems to be somehow related to this assert in clausesel.c: Assert(count_mv_attnums(list_union(stat_clauses, stat_conditions), relid, MV_CLAUSE_TYPE_MCV | MV_CLAUSE_TYPE_HIST) >= 2); With the assert in place, the code passes without a failure. After removing the assert (commenting it out), or even just changing it to Assert(count_mv_attnums(stat_clauses, relid, MV_CLAUSE_TYPE_MCV | MV_CLAUSE_TYPE_HIST) + count_mv_attnums(stat_conditions, relid, MV_CLAUSE_TYPE_MCV | MV_CLAUSE_TYPE_HIST) >= 2); i.e. removing the list_union, it fails as expected. The only thing that I can think of is that list_union happens to place the right stuff at the right position in memory - pure luck. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers