Thanks for reporting it. This is because of incorrect data typecasting. Attached is the patch that fixes this issue.
On Tue, Feb 21, 2017 at 2:58 PM, Mithun Cy <mithun...@enterprisedb.com>
wrote:
> On Fri, Feb 10, 2017 at 1:06 AM, Robert Haas <robertmh...@gmail.com>
> wrote:
>
> > Alright, committed with a little further hacking.
>
> I did pull the latest code, and tried
> Test:
> ====
> create table t1(t int);
> create index i1 on t1 using hash(t);
> insert into t1 select generate_series(1, 10000000);
>
> postgres=# SELECT spares FROM hash_metapage_info(get_raw_page('i1', 0));
> spares
> ------------------------------------------------------------
> ----------------
> {0,0,0,1,9,17,33,65,-127,1,1,0,1,-1,-1,-4,0,0,0,0,0,0,0,0,
> 0,0,0,0,0,0,0,0}
>
> spares are showing negative numbers; I think the wrong type has been
> chosen, seems it is rounding at 127, spares are defined as following
> uint32 hashm_spares[HASH_MAX_SPLITPOINTS]; /* spare pages before each
> splitpoint */
>
> it should be always positive.
>
> --
> Thanks and Regards
> Mithun C Y
> EnterpriseDB: http://www.enterprisedb.com
>
typecast_fix.patch
Description: invalid/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
