Thread: Open 6.5 items
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 vectorfrom 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, Pennsylvania19026
> 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
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
> 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, Pennsylvania19026
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