Re: Hashagg planning bug (8.0.1)

Rod Taylor <pg(at)rbt(dot)ca> writes:
> It's the = operator that Slony adds for xxid comparisons. I didn't even
> think of changes Slony would have made.

> ssdb=# select * from pg_operator where oid = 716373;
> oprname | oprnamespace | oprowner | oprkind | oprcanhash | oprleft | oprright | oprresult | oprcom | oprnegate | oprlsortop | oprrsortop | oprltcmpop | oprgtcmpop | oprcode | oprrest | oprjoin
> ---------+--------------+----------+---------+------------+---------+----------+-----------+--------+-----------+------------+------------+------------+------------+---------------+---------+-----------
> = | 2200 | 588 | b | t | 716353 | 716353 | 16 | 716373 | 716372 | 716371 | 716371 | 716371 | 716369 | _ssrep.xxideq | eqsel | eqjoinsel
> (1 row)

I think you need to have a word with the Slony boys. They shouldn't be
marking the operator oprcanhash if they aren't providing a valid hash
opclass for the datatype. Per the manual:

: To be marked HASHES, the join operator must appear in a hash index
: operator class. This is not enforced when you create the operator, since
: of course the referencing operator class couldn't exist yet. But
: attempts to use the operator in hash joins will fail at runtime if no
: such operator class exists. The system needs the operator class to find
: the data-type-specific hash function for the operator's input data
: type. Of course, you must also supply a suitable hash function before
: you can create the operator class.

regards, tom lane