Open 6.5 items

Bruce Momjian <maillist@candle.pha.pa.us>

What's this item? Do we have anything more specific?

SELECT * FROM test WHERE test IN (SELECT * FROM test) fails with strange error

postgres=> drop table test;
DROP
postgres=> create table test ( test int );
CREATE
postgres=> insert into test values ( 3);
INSERT 148950 1
postgres=> insert into test values ( 2);
INSERT 148951 1
postgres=> insert into test values ( 1);
INSERT 148952 1
postgres=> SELECT * FROM test WHERE test IN (SELECT * FROM test);
test
----
3
2
1
(3 rows)

postgres=>

Looks OK to me.

Keith.

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

add more detail inref/lock.sgml, ref/set.sgml to reflect
MVCC & locking changes.

Did you just do this, or is more coming from Vadim or yourself?

Markup sql.sgml, Stefan's intro to SQL

Done (well, sort of. My browser doesn't recognize some of the math
markup, but the hardcopy seems pretty good).

Generate Admin, User, Programmer hardcopy postscript

Programmer's Guide done.

Generate INSTALL and HISTORY from sgml sources.

INSTALL done.

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California

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;
DROP
test=> create table test(x int);
CREATE
test=> insert into test values (3);
INSERT 72169 1
test=> 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 704
test=>

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, Pennsylvania 19026

add more detail inref/lock.sgml, ref/set.sgml to reflect
MVCC & locking changes.

Did you just do this, or is more coming from Vadim or yourself?

I have done this. I want to add something about SERIALIZED/READ
COMMITTED. Vadim may want to add something to what I have done. It is
up to him.

Markup sql.sgml, Stefan's intro to SQL

Done (well, sort of. My browser doesn't recognize some of the math
markup, but the hardcopy seems pretty good).

Removed.

Generate Admin, User, Programmer hardcopy postscript

Programmer's Guide done.

Programmer's removed.

Generate INSTALL and HISTORY from sgml sources.

INSTALL done.

INSTALL removed.

-- 
  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, Pennsylvania 19026

Bruce Momjian wrote:

add more detail inref/lock.sgml, ref/set.sgml to reflect
MVCC & locking changes.

Did you just do this, or is more coming from Vadim or yourself?

I have done this. I want to add something about SERIALIZED/READ
COMMITTED. Vadim may want to add something to what I have done. It is
up to him.

I have to rewrite lock.sgml...

Vadim

[Charset koi8-r unsupported, filtering to ASCII...]

Bruce Momjian wrote:

add more detail inref/lock.sgml, ref/set.sgml to reflect
MVCC & locking changes.

Did you just do this, or is more coming from Vadim or yourself?

I have done this. I want to add something about SERIALIZED/READ
COMMITTED. Vadim may want to add something to what I have done. It is
up to him.

I have to rewrite lock.sgml...

I am adding a little about SET TRANSACTION. Feel free to change it.

-- 
  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, Pennsylvania 19026

Bruce Momjian wrote:

[Charset koi8-r unsupported, filtering to ASCII...]

Bruce Momjian wrote:

add more detail inref/lock.sgml, ref/set.sgml to reflect
MVCC & locking changes.

Did you just do this, or is more coming from Vadim or yourself?

I have done this. I want to add something about SERIALIZED/READ
COMMITTED. Vadim may want to add something to what I have done. It is
up to him.

I have to rewrite lock.sgml...

I am adding a little about SET TRANSACTION. Feel free to change it.

BTW, should we describe difference between two isolation levels
in set.sgml or it's enough to have such desc in User Guide?

Vadim

[Charset koi8-r unsupported, filtering to ASCII...]

Bruce Momjian wrote:

add more detail inref/lock.sgml, ref/set.sgml to reflect
MVCC & locking changes.

Did you just do this, or is more coming from Vadim or yourself?

I have done this. I want to add something about SERIALIZED/READ
COMMITTED. Vadim may want to add something to what I have done. It is
up to him.

I have to rewrite lock.sgml...

I have updated set.sgml and set.l to describe isolation levels. I don't
understand the new lock options very well.

-- 
  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, Pennsylvania 19026

BTW, should we describe difference between two isolation levels
in set.sgml or it's enough to have such desc in User Guide?

Vadim

I just did this.

-- 
  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, Pennsylvania 19026

Bruce Momjian wrote:

BTW, should we describe difference between two isolation levels
in set.sgml or it's enough to have such desc in User Guide?

Vadim

I just did this.

Thanks.

Vadim

Bruce Momjian wrote:

BTW, should we describe difference between two isolation levels
in set.sgml or it's enough to have such desc in User Guide?

Vadim

I just did this.

Thanks.

Vadim

lock [table] classname [[IN] [ROW|ACCESS] [SHARE|EXCLUSIVE] MODE]

I don't understand these options. I would be glad to write something if
you can explain it.

-- 
  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, Pennsylvania 19026

Bruce Momjian wrote:

lock [table] classname [[IN] [ROW|ACCESS] [SHARE|EXCLUSIVE] MODE]

^ ^
Remove them.
Also, there is yet another lock mode:

lock [table] classname IN SHARE ROW EXCLUSIVE MODE

I don't understand these options. I would be glad to write something if
you can explain it.

Actually, all lock modes are described in mvcc.sgml

Vadim

Bruce Momjian <maillist@candle.pha.pa.us> writes:

The issue is the issue:

test=> drop table test;
DROP
test=> create table test(x int);
CREATE
test=> insert into test values (3);
INSERT 72169 1
test=> 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 704

Hmm. Doesn't happen if one does

select * from test where x in (select x from test);

Is there any rational interpretation to the first query? test is not an
available column name, so I don't know what it is supposed to mean.

I'm having a hard time seeing this as a showstopper bug... at best it's
an error that needs to be caught somewhere where a better error message
can be given...

regards, tom lane

Bruce Momjian wrote:

lock [table] classname [[IN] [ROW|ACCESS] [SHARE|EXCLUSIVE] MODE]

^ ^
Remove them.
Also, there is yet another lock mode:

lock [table] classname IN SHARE ROW EXCLUSIVE MODE

Done.

I don't understand these options. I would be glad to write something if
you can explain it.

Actually, all lock modes are described in mvcc.sgml

I will take a look there.

-- 
  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, Pennsylvania 19026

Is there any rational interpretation to the first query? test is not an
available column name, so I don't know what it is supposed to mean.

It clearly is a meaningless query. Tablenames can not be used in that
context.

I'm having a hard time seeing this as a showstopper bug... at best it's
an error that needs to be caught somewhere where a better error message
can be given...

It isn't. It is just new from 6.4.2. I just move it to TODO if it is
not done, unless you want it moved now.

-- 
  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, Pennsylvania 19026

Bruce Momjian wrote:

lock [table] classname [[IN] [ROW|ACCESS] [SHARE|EXCLUSIVE] MODE]

^ ^
Remove them.
Also, there is yet another lock mode:

lock [table] classname IN SHARE ROW EXCLUSIVE MODE

I don't understand these options. I would be glad to write something if
you can explain it.

Actually, all lock modes are described in mvcc.sgml

I read it, and I don't understand the last one:

IN SHARE ROW EXCLUSIVE MODE

-- 
  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, Pennsylvania 19026

Bruce Momjian wrote:

Actually, all lock modes are described in mvcc.sgml

I read it, and I don't understand the last one:

IN SHARE ROW EXCLUSIVE MODE

It allows update a table only you. If two xacts acquire
SHARE lock and than both try to update the table then one
of them will be rolled back due to deadlock condition.
SHARE ROW EXCLUSIVE mode prevents such deadlock conditions.
But in difference from EXCLUSIVE mode it allows concurrent
SELECT FOR UPDATE, which could be used by other to ensure that
some rows will not be updated during his xaction.

As I already mentioned, our lock modes (except of Access
Share/Exclusive ones) are the same as in Oracle - I found that
their lock modes are very suitable for MVCC.

LOCK TABLE is not standard statement - so being compatible
with this big boy is good, isn't it?

Vadim

Bruce Momjian <maillist@candle.pha.pa.us>

What's this item? Do we have anything more specific?

SELECT * FROM test WHERE test IN (SELECT * FROM test) fails with strange error

postgres=> drop table test;
DROP
postgres=> create table test ( test int );

Try this:

create table test(x int);

CREATE
postgres=> insert into test values ( 3);
INSERT 148950 1
postgres=> insert into test values ( 2);
INSERT 148951 1
postgres=> insert into test values ( 1);
INSERT 148952 1
postgres=> SELECT * FROM test WHERE test IN (SELECT * FROM test);
test
----
3
2
1
(3 rows)

postgres=>

Looks OK to me.

Keith.

-- 
  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, Pennsylvania 19026