Re: [HACKERS] Open 6.5 items
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Open 6.5 items |
Дата | |
Msg-id | 199906040303.XAA02586@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open 6.5 items (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Open 6.5 items
|
Список | pgsql-hackers |
> 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) The issue is the issue:test=> drop table test;DROPtest=> create table test(x int);CREATEtest=> insert into test values (3);INSERT72169 1test=> select * from test where test in (select x from test);NOTICE: unknown node tag 704 in fireRIRonSubselect()NOTICE: Node is: { IDENT "test" }ERROR: ExecEvalExpr: unknown expression type 704test=> > > 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. Yes. I will remove it. > > > 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. Removed. > > refint problems > > What is the issue here? I thought regression tests were showing a problem? > > spinlock stuck problem > > I think this might be fixed... at least Vadim fixed one cause of it... Anyone? > > > 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). I will move it to TODO if it is not done for final. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: