Re: [HACKERS] Open 6.5 items

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> SELECT * FROM test WHERE test IN (SELECT * FROM test) fails with strange error

What is this one all about? I don't see a problem offhand:

regression=> create table test (test int);
CREATE
regression=> SELECT * FROM test WHERE test IN (SELECT * FROM test);
test
----
(0 rows)

regression=> insert into test values (33);
INSERT 189449 1
regression=> SELECT * FROM test WHERE test IN (SELECT * FROM test);
test
----
33
(1 row)

> Fix function pointer calls to take Datum args for char and int2 args(ecgs)

I think the consensus is to leave this alone until we can get more info.

> Regression test for new Numeric type

I think we need this in order to start flushing out any portability
problems that may exist in NUMERIC. (The first time I tried to use it
I found it didn't work on my box, so I'm harboring lingering doubts...)
Jan?

> Large Object memory problems

As far as I can tell, lo_read/lo_write etc do not leak memory anymore
(well, maybe they do within a transaction, but it's all cleaned up at
xact end).

There is a small leak every time a new LO is created, but I believe this
is not specific to LOs --- I think it is the same leak in the relcache
that occurs on the first reference to a relation of *any* kind. (See
my message "Memory leaks in relcache" dated 5/15/99.)

In short, I think this one can be closed out, or at least removed from
the 6.5-release-stoppers list.

> refint problems

What is the issue here?

> spinlock stuck problem

I think this might be fixed... at least Vadim fixed one cause of it...

> benchmark performance problem

The only thing I have been able to find out here is that btree is fairly
inefficient in the presence of *many* equal keys. I do not think this
is a showstopper, although if I get time I might try to fix the easiest-
to-fix aspect of it (linear search in bt_firsteq).

regards, tom lane