I recently joined the product management team for AWS RDS Postgres (after years at Oracle in their database team), and we are very interested in confirming (or not) that the fix for the problem below will be included in 9.5.2, and in the community’s plans (likely date) for releasing 9.5.2.
Is there an email list other than hackers where we can follow discussions on release plans for 9.5.2 (and future releases)?
On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Tobias Florek <postgres@ibotty.net> writes: >> When creating an index to use for an ORDER BY clause, a simple query >> starts to return more results than expected. See the following detailed >> log. > > Ugh. That is *badly* broken. I thought maybe it had something to do with > the "abbreviated keys" work, but the same thing happens if you change the > numeric column to integer, so I'm not very sure where to look. Who's > touched btree key comparison logic lately? > > (Problem is reproducible in 9.5 and HEAD, but not 9.4.)
Bisects down to:
606c0123d627b37d5ac3f7c2c97cd715dde7842f is the first bad commit commit 606c0123d627b37d5ac3f7c2c97cd715dde7842f Author: Simon Riggs <simon@2ndQuadrant.com> Date: Tue Nov 18 10:24:55 2014 +0000
Reduce btree scan overhead for < and > strategies
For <, <=, > and >= strategies, mark the first scan key as already matched if scanning in an appropriate direction. If index tuple contains no nulls we can skip the first re-check for each tuple.
Author: Rajeev Rastogi Reviewer: Haribabu Kommi Rework of the code and comments by Simon Riggs
Mea culpa.
Looks like we'll need a new release as soon as we can lock down a fix.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services