Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lAebo-0000ch-H6 for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Feb 2021 20:00:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lAebn-0003nj-D9 for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Feb 2021 20:00:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lAebn-0003nc-1k for pgsql-bugs@lists.postgresql.org; Fri, 12 Feb 2021 20:00:07 +0000 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lAebk-0001ao-Q8 for pgsql-bugs@lists.postgresql.org; Fri, 12 Feb 2021 20:00:05 +0000 Received: by mail-lj1-x22b.google.com with SMTP id q14so475151ljp.4 for ; Fri, 12 Feb 2021 12:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=X5MSlp0SAJXAHcUneCKXWeKWtrgtrpIqnXxLAHjISgs=; b=cubjj+HiV25/RZzblZPV1HTw40L8rViBMcsXYry1RUhtJbv8Z85donsVPWIzJCmQTg jLKQGNrFfqcOkAZpGVR3dBCkfw23PZuFM2z7rK2xFIVviz8wl50Uzxe6Xy+Aj5Rc4hhf FYrCzI/QY+B8UpcuoC5++JxFVMi6wd2hjxhZpp5d2rS+/cYmtMAU6CXt5Q653wmv+d4y QA7nS0n0xX6bbqWFLZmA9alY+iTVvd0y1Njl+FZTE0S1kl78cu9OPSdyuKbXVrEgUAUs UtfhEzUECJ9szz6ruBgbeAvYXkuquNgbk3SGCDLyrlZkvV4OdYSkorH6s79FQK8y/3y+ xpRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=X5MSlp0SAJXAHcUneCKXWeKWtrgtrpIqnXxLAHjISgs=; b=rWyOOwlkmfWQeSDdVsuGRLhDXt+HuNhjfQU9SN3EJ4uPLbwN4TDGAozBGb0Sdy+t3s khWiOMm81eC7vBWdoSuJXe7/7rnvh1TyD5doBmtyNngaXzIVP04taIViwbwoXGnc5To4 uhT0Hc/167IafTye+/twGDQBuu0MoGhQBH9l50oYCKCL95XIGEOqsWFIXpASb392OwfK LfFj1hdNzeuL8TrsfgsMBz8gYagTSvjvmwwP8EWd+w2/1ctvD9q4WO5/N3DJq8e5Lb2i zkyW/uOYw7yT7vgBZp+QlmR4MlCTPoap3GEpgSIiq885aKV5eNAR3zDK5BiQXmOtP6uR vCgA== X-Gm-Message-State: AOAM530L1FWigoGlVs/X7sEO7tNrhxEVvrhSVzmpCI+kvdXGioN6Grzi oRAcJH5TWvielWYdjeWQF1wF98sTWRg= X-Google-Smtp-Source: ABdhPJzyPG/T66fycjf/m4FwbnXvxhQnyj+I/4GsWrQmH9YRbbayD2rgK7p4djRqkHzmeAdMhR5W8A== X-Received: by 2002:a2e:85c3:: with SMTP id h3mr2515190ljj.431.1613160002671; Fri, 12 Feb 2021 12:00:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.6.69]) by smtp.gmail.com with ESMTPSA id y10sm1230217lfy.57.2021.02.12.12.00.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Feb 2021 12:00:02 -0800 (PST) Subject: Re: BUG #16863: Assert failed in set_plain_rel_size() on processing ~* with a long prefix To: pgsql-bugs@lists.postgresql.org References: <16863-35bf75b1b5ee4032@postgresql.org> From: Alexander Lakhin Message-ID: <6de0a0c3-ada9-cd0c-3e4e-2fa9964b41e3@gmail.com> Date: Fri, 12 Feb 2021 23:00:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <16863-35bf75b1b5ee4032@postgresql.org> Content-Type: multipart/mixed; boundary="------------B6666A231D32135E5BE54173" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------B6666A231D32135E5BE54173 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 12.02.2021 22:00, PG Bug reporting form wrote: > SELECT * FROM test WHERE t ~* ('^' || repeat('-', 500)); > ... > #2 0x0000559da7963ff8 in ExceptionalCondition ( > conditionName=conditionName@entry=0x559da7ab4690 "rel->rows > 0 || > IS_DUMMY_REL(rel)", > errorType=errorType@entry=0x559da79bf028 "FailedAssertion", > fileName=fileName@entry=0x559da7ab43b1 "allpaths.c", > lineNumber=lineNumber@entry=462) at assert.c:67 With the attached debugging patch applied I see that rel->rows there is NaN. At the end of the walk by the following calls: set_plain_rel_size -> set_baserel_size_estimates -> clauselist_selectivity -> clauselist_selectivity_simple -> clause_selectivity -> restriction_selectivity -> icregexeqsel -> patternsel -> patternsel_common -> pattern_fixed_prefix -> regex_fixed_prefix -> regex_selectivity I've found a division that produces NaN: sel /= pow(FIXED_CHAR_SEL, fixed_prefix_len); The complete output with the debugging code: psql:500.sql:2: INFO:  sel: 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, FIXED_CHAR_SEL: 0.200000, fixed_prefix_len: 500, pow: 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 psql:500.sql:2: INFO:  sel: NaN psql:500.sql:2: INFO:  rel->rows: NaN; nrows: NaN psql:500.sql:2: INFO:  rel->rows: NaN psql:500.sql:2: server closed the connection unexpectedly With the prefix length 400 the output is different: psql:400.sql:2: INFO:  sel: 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002582249878086965166223199366465225696632326517795503118666931124080740300000000000000000000000000000000000000000000000000, FIXED_CHAR_SEL: 0.200000, fixed_prefix_len: 400, pow: 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002582249878086966144821031402096464952544460966116815567078211594740854000000000000000000000000000000000000000000000000000 psql:400.sql:2: INFO:  sel: 1.000000 psql:400.sql:2: INFO:  rel->rows: 7.000000; nrows: 6.800000 psql:400.sql:2: INFO:  rel->rows: 7.000000 On the master with the length 500 there is no assertion failure but the row count is strange: psql:master500.sql:3: INFO:  sel: 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, FIXED_CHAR_SEL: 0.200000, fixed_prefix_len: 500, pow: 0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 psql:master500.sql:3: INFO:  sel: NaN psql:master500.sql:3: INFO:  rel->rows: 10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104.000000; nrows: NaN psql:master500.sql:3: INFO:  rel->rows: 10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104.000000 By the way, if the following check in restriction_selectivity() is intended to throw error on an invalid selectivity, shouldn't the isnan(result) test be appended here?:     if (result < 0.0 || result > 1.0)         elog(ERROR, "invalid restriction selectivity: %f", result); Best regards, Alexander --------------B6666A231D32135E5BE54173 Content-Type: text/x-patch; charset=UTF-8; name="debug_sel.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="debug_sel.patch" diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index e7a3e92bc20..726494bd98d 100644 --- a/src/backend/optimizer/path/allpaths.c +++ b/src/backend/optimizer/path/allpaths.c @@ -459,6 +459,7 @@ set_rel_size(PlannerInfo *root, RelOptInfo *rel, /* * We insist that all non-dummy rels have a nonzero rowcount estimate. */ +elog(INFO, "rel->rows: %f", rel->rows); Assert(rel->rows > 0 || IS_DUMMY_REL(rel)); } diff --git a/src/backend/optimizer/path/costsize.c b/src/backend/optimizer/path/costsize.c index ffd2bf87834..3213522d5bc 100644 --- a/src/backend/optimizer/path/costsize.c +++ b/src/backend/optimizer/path/costsize.c @@ -4658,6 +4658,7 @@ set_baserel_size_estimates(PlannerInfo *root, RelOptInfo *rel) NULL); rel->rows = clamp_row_est(nrows); +elog(INFO, "rel->rows: %f; nrows: %f", rel->rows, nrows); cost_qual_eval(&rel->baserestrictcost, rel->baserestrictinfo, root); diff --git a/src/backend/utils/adt/like_support.c b/src/backend/utils/adt/like_support.c index bcfbaa1c3d1..aeb3a768692 100644 --- a/src/backend/utils/adt/like_support.c +++ b/src/backend/utils/adt/like_support.c @@ -1443,8 +1443,10 @@ regex_selectivity(const char *patt, int pattlen, bool case_insensitive, } /* If there's a fixed prefix, discount its selectivity */ +elog(INFO, "sel: %0.400f, FIXED_CHAR_SEL: %f, fixed_prefix_len: %d, pow: %0.400f", sel, FIXED_CHAR_SEL, fixed_prefix_len, pow(FIXED_CHAR_SEL, fixed_prefix_len)); if (fixed_prefix_len > 0) sel /= pow(FIXED_CHAR_SEL, fixed_prefix_len); +elog(INFO, "sel: %f", sel); /* Make sure result stays in range */ CLAMP_PROBABILITY(sel); --------------B6666A231D32135E5BE54173--