Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6

From: dg(at)illustra(dot)com (David Gould)
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart)
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us, scrappy(at)hub(dot)org, dz(at)cs(dot)unitn(dot)it, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6
Date: 1998-03-17 06:38:14
Message-ID: 9803170638.AA29303@hawk.illustra.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> David Gould wrote:
> > 
> > > > > > Can you submit an appropriate patch that can be included in the
> > > > > > mega-patch to be created on Sunday?
> > >
> > > > > are hard to de-couple.  Now, I did not know we supported NetBSD on
> > > > > VAX. Does it work, anyone?  Can I remove it?
> > > >
> > > > NetBSD on VAX in on our supported list, and was verified for v6.3 by Tom
> > > > Helbekkmo.
> > > >
> > > > > This is going to be pretty tough to test on every platform we support,
> > > > > so if it is done now, it will have to be done carefully.
> > > >
> > > > Is this behavior in v6.2.x? In any case, if it is anything but minimally
> > > > trivial, it should be given a test on every supported platform, since it
> > > > hits the heart of the platform-specific code, doesn't it? Seems like it
> > > > should be put into the CVS tree and shaken out until the next release...
> > >
> > > Yea, that is what I was hinting at.
> > >
> > > --
> > > Bruce Momjian                          |  830 Blythe Avenue
> > > maillist(at)candle(dot)pha(dot)pa(dot)us              |  Drexel Hill, Pennsylvania 19026
> > 
> > I tend to agree but am willing to compromise.
> > 
> > Can we do only the easy platforms at this time
> > If this will work, I am willing to hack this together tomorrow.
> > What is the time frame for accepting a patch like this?
> 
> What do you think it would take to exercise the patch heavily enough on
> any of the affected platforms to ensure that it behaves no worse than
> the current code? Is a test case easy to set up and run? If so, you can
> probably get ~5 platforms tested in the next few days, and reduce the
> risk of including this in the mega-patch.

Simple but clumsy test:

Multiple backends all doing single row inserts into private tables. Run it
for a fixed time period and add up the total number of rows. Do this for both
a small (eg 2) and large (eg 20 or 40) number of backends.

psuedo perl /sh / sql follows
# driver <number of users> <delay time> <run time>
synchtime = timenow
starttime = synctime + delaytime;
endtime = starttime + runtime
for user 1 to number of users
   singleuser synchtime delay_time run_time

# singleuser <userno> <starttime> <endtime>
exec sql 'create table user$user (i int);'

sleep until start time
n = 1;
while timenow < endtime
   exec sql "insert into user$user values($n);"

print "user $user inserted $n"

The figure of merit is the total number of inserts. Oh and that the system
does not fall over.

But, it may be best to leave this until after the mega patch. I am not sure
I want to share the blame ;-).

Just to fill me in, where does the mega patch fall in with the next release
snapshot? That is, if this misses the mega patch is it waiting until 6.4?

-dg


David Gould            dg(at)illustra(dot)com           510.628.3783 or 510.305.9468 
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
 - I realize now that irony has no place in business communications.


In response to

Responses

pgsql-hackers by date

Next:From: Peter T MountDate: 1998-03-17 07:10:04
Subject: Re: Problem with JDBC interface in Postgresql-6.3
Previous:From: The Hermit HackerDate: 1998-03-17 04:51:23
Subject: Re: [HACKERS] Re: [PATCHES] patches for 6.2.1p6

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group