
SELECT * FROM test WHERE test IN (SELECT * FROM test) fails with strange error
Fix function pointer calls to take Datum args for char and int2 args(ecgs)
Regression test for new Numeric type
Large Object memory problems
refint problems
invalidate cache on aborted transaction
spinlock stuck problem
benchmark performance problem
add more detail inref/lock.sgml, ref/set.sgml to reflect MVCC & locking changes.

Markup sql.sgml, Stefan's intro to SQL
Generate Admin, User, Programmer hardcopy postscript
Generate INSTALL and HISTORY from sgml sources.


 
-- 
  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

Thu, 3 Jun 1999 17:01:35 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Open 6.5 items
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

Thu, 03 Jun 1999 19:05:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Open 6.5 items 
> 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

Fri, 04 Jun 1999 02:01:03 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Open 6.5 items
> 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

Thu, 3 Jun 1999 23:03:03 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
> > 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

Thu, 3 Jun 1999 23:06:37 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
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

Fri, 04 Jun 1999 11:23:31 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Open 6.5 items
[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

Thu, 3 Jun 1999 23:28:47 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
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

Fri, 04 Jun 1999 11:31:34 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Open 6.5 items
[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

Thu, 3 Jun 1999 23:45:07 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
> 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

Thu, 3 Jun 1999 23:46:00 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
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

Fri, 04 Jun 1999 11:48:11 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Open 6.5 items
> 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

Thu, 3 Jun 1999 23:51:47 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
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

Fri, 04 Jun 1999 12:11:20 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Open 6.5 items
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

Fri, 04 Jun 1999 00:15:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Open 6.5 items 
> 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

Fri, 4 Jun 1999 00:16:02 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
> 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

Fri, 4 Jun 1999 00:18:01 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
> 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

Fri, 4 Jun 1999 00:33:57 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
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

Fri, 04 Jun 1999 14:33:46 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Open 6.5 items
Vadim Mikheev wrote:
> Actually, all lock modes are described in mvcc.sgml

I have all the files in doc/src/sgml but I don't understand how to
view these except in raw form. I looked at the Makefile and see
it requires style sheets ($HDSL) which are not included with
the cvs distribution. I assume that these are used to gen html
files, but can find no reference to this.

Am I missing something?

--------
Regards
Theo

Sun, 06 Jun 1999 13:33:51 +0200
Theo Kramer <theo@flame.co.za>
Re: [HACKERS] Open 6.5 items
> > Actually, all lock modes are described in mvcc.sgml
> I have all the files in doc/src/sgml but I don't understand how to
> view these except in raw form. I looked at the Makefile and see
> it requires style sheets ($HDSL) which are not included with
> the cvs distribution. I assume that these are used to gen html
> files, but can find no reference to this.
> Am I missing something?

There is an appendix in the v6.4 and v6.5beta which discusses the
documentation and how to generate it. It includes information on
packages, where to get them, and how to install them.

There are daily snapshots built of the html, which run to completion
unless something gets broken in the sgml markup, in which case there
may be a failed snapshot build for a day or two until I fix the
markup.

                    - Thomas

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

Mon, 07 Jun 1999 06:53:54 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Open 6.5 items