Re: BRIN range operator class

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Emre Hasegeli <emre(at)hasegeli(dot)com>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BRIN range operator class
Date: 2015-05-06 21:34:45
Message-ID: 20150506213445.GA2523@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I again have to refuse the notion that removing the assert-only block
without any replacement is acceptable. I just spent a lot of time
tracking down what turned out to be a bug in your patch 07:

/* Adjust maximum, if B's max is greater than A's max */
- needsadj = FunctionCall2Coll(minmax_get_procinfo(bdesc, attno,
- PROCNUM_GREATER),
- colloid, col_b->bv_values[1], col_a->bv_values[1]);
+ frmg = minmax_get_strategy_procinfo(bdesc, attno, attr->atttypid,
+ BTGreaterStrategyNumber);
+ needsadj = FunctionCall2Coll(frmg, colloid, col_b->bv_values[0],
+ col_a->bv_values[0]);

Note the removed lines use array index 1, while the added lines use
array index 0. The only reason I noticed this is because I applied this
patch without the others and saw the assertion fire; how would I have
noticed the problem had I just removed it?

Let's think together and try to find a reasonable way to get the union
procedures tested regularly. It is pretty clear that having them run
only when the race condition occurs is not acceptable; bugs go
unnoticed.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-06 21:59:55 Re: BRIN range operator class
Previous Message Tom Lane 2015-05-06 21:33:03 Re: Patch for bug #12845 (GB18030 encoding)