
SELECT * FROM test WHERE test IN (SELECT * FROM test) fails with strange error
When creating a table with either type inet or type cidr as a primary,unique
   key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equal
crypt_loadpwdfile() is mixing and (mis)matching memory allocation
  protocols, trying to use pfree() to release pwd_cache vector from realloc()
Fix function pointer calls to take Datum args for char and int2 args(ecgs)

Do we want pg_dump -z to be the default?

Make psql \help, man pages, and sgml reflect changes in grammar
Markup sql.sgml, Stefan's intro to SQL
Markup cvs.sgml, cvs and cvsup howto
Add figures to sql.sgml and arch-dev.sgml, both from Stefan
Include Jose's date/time history in User's Guide (neat!)
Generate Admin, User, Programmer hardcopy postscript


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

Wed, 26 May 1999 16:29:56 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Open 6.5 items
> Markup sql.sgml, Stefan's intro to SQL

Still needs a look, since the math markup is not looking good in my
browser. But I can easily fall back to disabling those parts of the
doc for now.

> Markup cvs.sgml, cvs and cvsup howto

Done.

> Add figures to sql.sgml and arch-dev.sgml, both from Stefan

Done.

> Include Jose's date/time history in User's Guide (neat!)

Done.

> Generate Admin, User, Programmer hardcopy postscript

Not yet, and not likely by June 1. Also, there are additional items:

Generate INSTALL and HISTORY from sgml sources.
Update ref/lock.sgml, ref/set.sgml to reflect MVCC and locking
changes.


                       - Thomas

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

Thu, 27 May 1999 16:34:13 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Open 6.5 items
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> crypt_loadpwdfile() is mixing and (mis)matching memory allocation
>   protocols, trying to use pfree() to release pwd_cache vector from realloc()

Didn't this just get fixed?

> Fix function pointer calls to take Datum args for char and int2 args(ecgs)

This still needs to be done, and it looks like a lot of tedious
gruntwork :-(.  Do we have a volunteer?

I think we still have some unresolved issues about locking and about
handling of multi-segment tables.  Shouldn't those be on the TODO list?
If they were fixed to everyone's satisfaction, it wasn't apparent from
the list traffic...

I am currently trying to investigate the poor performance reported by
Edmund Mergl --- since gprof doesn't really work on my Linux box, I
am reduced to running a profilable postmaster on my HPUX box with the
database area NFS-mounted from the Linux box, where there is enough disk
space for the benchmark.  This setup gives new meaning to the term
"slow", but I should be able to get a useful profile out of it.  If that
turns up anything significant and readily fixable, I might propose
delaying 6.5 for a fix.

			regards, tom lane

Thu, 27 May 1999 13:44:59 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Open 6.5 items 
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > crypt_loadpwdfile() is mixing and (mis)matching memory allocation
> >   protocols, trying to use pfree() to release pwd_cache vector from realloc()
> 
> Didn't this just get fixed?
> 
> > Fix function pointer calls to take Datum args for char and int2 args(ecgs)
> 
> This still needs to be done, and it looks like a lot of tedious
> gruntwork :-(.  Do we have a volunteer?

Can we throw ecps a flag to disable it from doing this until we can
address the problem more globally?

> 
> I think we still have some unresolved issues about locking and about
> handling of multi-segment tables.  Shouldn't those be on the TODO list?
> If they were fixed to everyone's satisfaction, it wasn't apparent from
> the list traffic...

I have heard grumbing about these, but have not seen a "Oh, I see the
problem now" report, so I am hoping someone will re-interete that it is
a problem.  I have trouble telling if something is resoved.  Does anyone
know of problems?  My recollection is that the multi-segment stuff is
done, and the objector retracted his objection.  I thought the locking
was behaving as it should.  Comments?


> I am currently trying to investigate the poor performance reported by
> Edmund Mergl --- since gprof doesn't really work on my Linux box, I
> am reduced to running a profilable postmaster on my HPUX box with the
> database area NFS-mounted from the Linux box, where there is enough disk
> space for the benchmark.  This setup gives new meaning to the term
> "slow", but I should be able to get a useful profile out of it.  If that
> turns up anything significant and readily fixable, I might propose
> delaying 6.5 for a fix.

I can run it here.  What do you want me to do?


-- 
  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, 27 May 1999 13:52:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Open 6.5 items
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> I am currently trying to investigate the poor performance reported by
>> Edmund Mergl --- since gprof doesn't really work on my Linux box, I
>> am reduced to running a profilable postmaster on my HPUX box with the
>> database area NFS-mounted from the Linux box, where there is enough disk
>> space for the benchmark.  This setup gives new meaning to the term
>> "slow", but I should be able to get a useful profile out of it.

> I can run it here.  What do you want me to do?

What I'm after currently is a profile of the no-indexes case.  Build a
one-million-row test database using the script Edmund provided (see
his message of 22 May 1999 06:39:25 +0200), but stop the script before
it invokes "make_idx".  Then, with a backend compiled -pg, run this
query:
	update bench set k500k = k500k + 1 where k100 = 30
and send me the gprof results.

If you have time, it'd also be useful to have a profile of the same
update with indexes in place (run Edmund's make_idx script and then do
the update again).

I'm pretty close to having a profile from my NFS lashup, but it would
be nice to have profiles of the same thing from other machines as
a cross-check that no artifacts are getting introduced...

			thanks, tom lane

Thu, 27 May 1999 16:39:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Open 6.5 items 