Re: Hashagg planning bug (8.0.1)

On T, 2005-05-10 at 13:17 -0400, Tom Lane wrote:
> 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:

Why does slony use its own transaction id type (xxid) in the first
place, why can't we just use standard xid ?

Also, perhaps we could get the getcurrentxid() function accepted in
postgresql core, maybe as pg_get_current_xid(), perhaps together with
pg_oldest_running_xid() and pg_oldest_visible_xid() for determining if
there is any benefit from running vacuum.

I think that knowing current xid is something other applications besides
slony can benefit from.

--
Hannu Krosing <hannu(at)skype(dot)net>