From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: negative bitmapset member not allowed Error with partition pruning |
Date: | 2018-07-27 02:42:45 |
Message-ID: | CAKJS1f-z_EZxLZeb7dbJ5G89O6c=7CBPr4Z4WHJiHnBHB+8R3Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27 July 2018 at 13:35, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2018/07/27 1:28, Tom Lane wrote:
>> (BTW, I'm not sure that it was wise to design bms_add_range to fail for
>> empty ranges. Maybe it'd be better to redefine it as a no-op for
>> upper < lower?)
>
> FWIW, I was thankful that David those left those checks there, because it
> helped expose quite a few bugs when writing this code or perhaps that was
> his intention to begin with, but maybe he thinks differently now (?).
I think it's more useful to keep as a bug catcher, although I do
understand the thinking behind just having it be a no-op.
Partition pruning is complex code so I think additional caution is
warranted. People are more likely to notice the error and complain.
It's likely especially useful with tools like sqlsmith, as I imagine
it does not validate the actual results of queries (does it?). but I'm
pretty sure that the ERROR would get flagged up.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-27 02:42:47 | Re: Deprecating, and scheduling removal of, pg_dump's tar format. |
Previous Message | Christophe Pettus | 2018-07-27 02:41:39 | Re: Deprecating, and scheduling removal of, pg_dump's tar format. |