Re: negative bitmapset member not allowed Error with partition pruning

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-07-30T22:54:46Z
Lists: pgsql-hackers
On 2018-Jul-27, David Rowley wrote:

> On 27 July 2018 at 15:14, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> > Well, my thinking is that it helps nobody if call sites have to have
> > explicit workarounds for a totally-arbitrary refusal to handle edge
> > cases in the primitive functions.  I do not think that is good software
> > design.  If you want to have assertions that particular call sites are
> > specifying nonempty ranges, put those in the call sites where it's
> > important.  But as-is, this seems like, say, defining foreach() to
> > blow up on an empty list.
> 
> Okay, that's a fair point. I agree,  adding Asserts at the current
> call sites seems better.

Given the discussion, I pushed two commits: first, bms_add_range returns
the input bms if the range is empty, also adding Rajkumar's test case,
which I also verified to reproduce the bug, and passes (for me) with the
bms_add_range change.

The second commit includes the proposed asserts, but not the change to
avoid calling bms_add_range when the range is empty.

Thanks!

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Verify range bounds to bms_add_range when necessary

  2. Change bms_add_range to be a no-op for empty ranges