Open 6.5 items

Do we want pg_dump -z to be the default?

I would say yes. A dump without switches should dump everything
including permissions. This is what people use to backup their db,
but would be of no use if they lose their permissions.

Andreas

Do we want pg_dump -z to be the default?

I would say yes. A dump without switches should dump everything
including permissions. This is what people use to backup their db,
but would be of no use if they lose their permissions.

This is the first person to express an opinion, and I agree with it.
Does anyone have more comments? My idea is to print out a message that
the -z flag is now the default, and supply another flag to skip
permission dumping.

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

On 27-May-99 Bruce Momjian wrote:

Do we want pg_dump -z to be the default?

I would say yes. A dump without switches should dump everything
including permissions. This is what people use to backup their db,
but would be of no use if they lose their permissions.

This is the first person to express an opinion, and I agree with it.
Does anyone have more comments? My idea is to print out a message that
the -z flag is now the default, and supply another flag to skip
permission dumping.

I agree. It was brought up a number of months ago when I moved a
database to a new machine, but that was about it.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

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

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