Bruce Momjian <maillist@candle.pha.pa.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