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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Vadim Mikheev
Дата:
Сообщение: Re: [HACKERS] Priorities for 6.6
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Open 6.5 items