Re: [HACKERS] pg_advisor schema proof of concept

[Richard Huxton]

On Thursday 25 March 2004 21:59, Robert Treat wrote:
> On Thu, 2004-03-25 at 11:31, Fabien COELHO wrote:
>
> Are you planning on making some type of differentiation on advise that
> is performance based rather than advise that is theory based?  I see
> both cases being hinted at and it seems like a subtle but important
> piece of information...

Fabien already has - there is an "advice_kind" table, values: misc, design, 
performance.


-- 
  Richard Huxton
  Archonet Ltd

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] pg_advisor schema proof of concept

[Fabien COELHO]

Dear Josh,

> > That's why advices are "graded" from info to error in the current
> > preliminary version.
>
> > Advices that may or may not be good depending on undecidable elements
> > have a lower grade. For instance, most attributes should be "NOT NULL"
> > from a statistical point of view, but it is perfectly legitimate to
> > have nullable attributes mostly anywhere, so the corresponding advices
> > is just an "info".
>
> Are you planning on making some type of differentiation on advise that
> is performance based rather than advise that is theory based?  I see
> both cases being hinted at and it seems like a subtle but important
> piece of information...

The current working status is that advices have a grade (info notice
warning error) and a kind (design, performance, meta).

More precise and subtle classification can be though of, but the interest
depends on the total number of advices in the system. Now there is around
a dozen of them, so there is no urge. It is easy to add some more
classification if needed.

Another place where such information can be given is within the
description which illustrate the advice. I think maybe this would be a
better place.

> LAMP = Linux Apache {middleware} Postgres

[JOKE] What about renaming postgreSQL myPostgres? ;-)

-- 
Fabien Coelho - [EMAIL PROTECTED]

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [PERFORM] [HACKERS] fsync method checking

[Manfred Spraul]

[EMAIL PROTECTED] wrote:

Compare file sync methods with one 8k write:
   (o_dsync unavailable)  
   open o_sync, write   6.270724
   write, fdatasync13.275225
   write, fsync,   13.359847
 

Odd. Which filesystem, which kernel? It seems fdatasync is broken and 
syncs the inode, too.

--
   Manfred
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: [HACKERS] Per database users/admins, handy for database virtual hosting...

[Sean Chittenden]

I haven't read much in the last few months, but archives from 2002 
suggested there wasn't much on the table in terms of making this 
happen beyond adding a function that runs as a DBA to create users 
(which I've done).
Well, the db_user_namespace GUC var has been implemented, but it is a 
hack.
And it doesn't handle the case of letting the local database admin 
create users (without giving them access to the rest of the database), 
which is what I'm after.  -sc

--
Sean Chittenden
---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Per database users/admins, handy for database virtual hosting...

[Sean Chittenden]

You can't think that allowing the same name to appear
globally and locally is a good idea.
Actually, I do think it is a good idea.

If I say "GRANT TO foo", who am
I granting privileges to?
SET username_precedence TO LOCAL,GLOBAL;   -- I like GLOBAL more than 
CLUSTER
GRANT TO foo;
SET username_precedence TO GLOBAL,LOCAL;
GRANT TO foo;

And I don't want to say that there is no
difference because they are the same user.
Agreed, they should be the same user.

That will open up some nasty
security holes, eg, being able to pretend that you are the global
postgres superuser if you can set the password for a local user by the
same name.
Agreed, but if a cluster is using LOCAL USERs, I doubt highly that 
CLUSTER/GLOBAL users would be in use much beyond super users.  -sc

--
Sean Chittenden
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
 subscribe-nomail command to [EMAIL PROTECTED] so that your
 message can get through to the mailing list cleanly

[HACKERS] Returning number of rows - Copy In function

[mike g]

Hello,

I was looking at putting the code for this in copy.c
CopyReadLineFunction.

If I do a printf at point A it compiles, installs, runs, doesn't display
any data after running initdb and returns a result when a COPY FROM is
executed in psql.

If I do a printf at point B it compiles, installs, and then crashes when
executing initdb.


loading pg_description ... initdb: child process exited with exit code
139
initdb: failed


Thoughts on why A is ok but B is not?

I don't really want to send any results to the screen if it is called
when first creating a database.  I have looked for something like
CMD_SELECT to identify when Initdb is executed.

Is their an existing variable I can check that I have not found?

Index: copy.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/commands/copy.c,v
retrieving revision 1.218
diff -b -B -r1.218 copy.c
107c108
< 
---
> int co_rows_inserted = 0;
1448a1451,1452
> /*my code*/
> co_rows_inserted = 0;
1782a1787
>   /*this is being called during database creation!!*/
1786a1792,1818
> co_rows_inserted = copy_lineno;
> char *buf = " ";
> 
> gcvt(co_rows_inserted, 10, buf);
> printf("%i   %s\n",co_rows_inserted, buf);/*ok here point A*/
> 
> 	if (co_rows_inserted > 0)
> 		{
>   printf("%i   %s\n",co_rows_inserted, buf);/*not ok here point B*/
>   /*
>   StringInfoData msgbuf;
>   pq_beginmessage(&msgbuf, ' ');
>   pq_sendstring(&msgbuf, gettext(buf) );
>   pq_endmessage(&msgbuf);
>*/
>  }   
> else if (co_rows_inserted == 0)
>{
>ereport(WARNING,(errcode(ERRCODE_BAD_COPY_FILE_FORMAT),
> errmsg ("File used to import data is empty."),
> errhint("Double check file name used")));
>}else if (co_rows_inserted < 0)
> {
> ereport(ERROR,
>(errcode(ERRCODE_BAD_COPY_FILE_FORMAT),   errmsg("Rows copied were less than zero.  Copy function has been broken"),
> errhint("File a bug please")));
> }


signature.asc
Description: This is a digitally signed message part

Re: [HACKERS] Per database users/admins, handy for database virtual hosting...

[Tom Lane]

Sean Chittenden <[EMAIL PROTECTED]> writes:
>> Come to think of it, the same risk of conflict applies for user 
>> *names*, and we can't easily make an end-run around that.

> That's why I used UNION ALL in my example.  Reserved usernames that are 
> in the cluster should be just as valid as usernames that are in the 
> local database table.

I don't follow.  You can't think that allowing the same name to appear
globally and locally is a good idea.  If I say "GRANT TO foo", who am
I granting privileges to?  And I don't want to say that there is no
difference because they are the same user.  That will open up some nasty
security holes, eg, being able to pretend that you are the global
postgres superuser if you can set the password for a local user by the
same name.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Per database users/admins, handy for database virtual hosting...

[Sean Chittenden]

What's the feasibility of augmenting the system catalogs so that
something similar to the following is possible:

CREATE VIEW pg_catalog.pg_shadow AS
SELECT usename, usesysid, usecreatedb, usesuper,
usecatupd, passwd, valuntil, useconfig
FROM pg_catalog.pg_shadow_cluster
UNION ALL
SELECT usename, usesysid, usecreatedb, usesuper,
usecatupd, passwd, valuntil, useconfig
FROM pg_catalog.pg_shadow_db;
The main problem I can see is usesysid conflicts.  For example suppose
userid 42 is created in database A, and then someone in database B
decides to create a global user with id 42.  The latter someone can't
even see that he's causing a problem in database A :-(
Hrm...  that's true.  The UID sequence would be shared, but that 
doesn't prevent someone from forcing a DBA from having a non-sequential 
UID.  Here's a list of the scenarios that I can think of:

LOCAL USERs, as you suggest later, are bound to a given database, who 
cares if the local DBA mucks with the UID of the user?  They're still 
confined to their local database and there's no risk to the integrity 
of the system.  A local DBA shouldn't be able to muck with 
pg_shadow_cluster anyway, so no harm should be possible.

Let's say a local DBA creates a user with UID that conflicts with a 
cluster wide user.  What's the worst that could happen?  The UID of the 
cluster wide user inherits perms of the local user with the same UID.  
In most deployment scenarios where system admins would deploy 
PostgreSQL and use LOCAL USERS, the CLUSTER USERS are probably a DBAs 
with his/her pg_catalog.pg_shadow_cluster.usesuper = TRUE, so 
inheriting privs is of little consequence.  If a CLUSTER USER is just a 
normal user, then the permissions could get wonky.  It may be worth 
while logging a UID conflict and closing the connection for security 
reasons if usesuper = FALSE.  It seems like it'd be possible to have 
TRIGGERs on pg_shadow_db that'd check to make sure the UID wasn't 
already in use and make a stink if it were already in use in the 
cluster's catalog.  You can only protect people from wandering off the 
range so far...

Beyond a database picking up problems, I can't think of any other 
consequences... at least not that'd affect the entire cluster... but 
I'm still a bit new to the problem and may have missed something.

Maybe something dirty like reserving separate ranges of sysid for local
and global users would get the job done, but I haven't spent any time
trying to poke holes in that idea...
Well, it's reasonably tried and true in the *NIX world with reserved 
UIDs being the only ones allowed to bind to ports less than 1024.  
Beyond being arbitrary limits, it seems to have worked well to date.

Reserving the lower 10K UIDs for cluster users isn't a bad idea... 
going further, given that I haven't heard of a database with more than 
1B users... use 2^30 through 2^31 as the UID range for local users and 
0 through (2^30 - 1) as the range for cluster wide UIDs.  If someone 
gripes about having only 1B UIDs for cluster wide/local admin 
purposes...

Come to think of it, the same risk of conflict applies for user 
*names*,
and we can't easily make an end-run around that.
That's why I used UNION ALL in my example.  Reserved usernames that are 
in the cluster should be just as valid as usernames that are in the 
local database table.  I'm not sure how the authentication bit works 
internally, but that seems like a matter of changing the routine to do:

SELECT TRUE FROM pg_catalog.pg_shadow WHERE usename = :username AND 
password = :pw;

and checking to see if the query returns at least one row.

And then set up RULEs to direct INSERTs, UPDATEs, DELETEs from
pg_shadow to pg_shadow_db.  CREATE USER/ALTER USER operates on
pg_catalog_db, then CREATE CLUSTER USER/ALTER CLUSTER USER operates on
pg_catalog_cluster.
Nope, other way round, default behavior for backwards compatibility 
must
be to create cluster-wide users.  CREATE LOCAL USER is what to add.
Ah, good point.  -sc

--
Sean Chittenden
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [HACKERS] Per database users/admins, handy for database virtual hosting...

[Tom Lane]

Sean Chittenden <[EMAIL PROTECTED]> writes:
> What's the feasibility of augmenting the system catalogs so that 
> something similar to the following is possible:

> CREATE VIEW pg_catalog.pg_shadow AS
>   SELECT usename, usesysid, usecreatedb, usesuper,
>   usecatupd, passwd, valuntil, useconfig
>   FROM pg_catalog.pg_shadow_cluster
> UNION ALL
>   SELECT usename, usesysid, usecreatedb, usesuper,
>   usecatupd, passwd, valuntil, useconfig
>   FROM pg_catalog.pg_shadow_db;

The main problem I can see is usesysid conflicts.  For example suppose
userid 42 is created in database A, and then someone in database B
decides to create a global user with id 42.  The latter someone can't
even see that he's causing a problem in database A :-(

I'd be in favor of this if we could find an answer to that one.

Maybe something dirty like reserving separate ranges of sysid for local
and global users would get the job done, but I haven't spent any time
trying to poke holes in that idea...

Come to think of it, the same risk of conflict applies for user *names*,
and we can't easily make an end-run around that.

> And then set up RULEs to direct INSERTs, UPDATEs, DELETEs from 
> pg_shadow to pg_shadow_db.  CREATE USER/ALTER USER operates on 
> pg_catalog_db, then CREATE CLUSTER USER/ALTER CLUSTER USER operates on 
> pg_catalog_cluster.

Nope, other way round, default behavior for backwards compatibility must
be to create cluster-wide users.  CREATE LOCAL USER is what to add.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Email addresses on developer bios site

[Marc G. Fournier]

On Fri, 26 Mar 2004, Christopher Kings-Lynne wrote:

> >>Is there any chance we could get our email addresses obfuscated to
> >>prevent spam?
> >
> > Just an FYI, but just by posting, you do realize that your email address
> > is propogated to every Usenet server in the world, as well as several
> > search engines like Google and Gname, right?
>
> I'm well aware of that, since you, bruce and tom currently attempt to
> sell me Viagra several times a day... :)

Ya, and sales have been most disappointing *sigh*


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Per database users/admins, handy for database virtual hosting...

[Neil Conway]

On 25-Mar-04, at 8:18 PM, Sean Chittenden wrote:
I haven't read much in the last few months, but archives from 2002 
suggested there wasn't much on the table in terms of making this 
happen beyond adding a function that runs as a DBA to create users 
(which I've done).
Well, the db_user_namespace GUC var has been implemented, but it is a 
hack.

-Neil

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: [HACKERS] Nested transaction proposal - take N (N > 2)

[Christopher Kings-Lynne]

a  c
0  0  transaction in progress, the owning backend knows whether
  it is a main- or a sub-transaction, other backends don't care
1  0  aborted, nobody cares whether main- or sub-transaction
0  1  committed main-transaction or - with shortcut 2 - a sub-
  transaction that's known committed to all active transactions
1  1  committed sub-transaction, have to look for parent in
  pg_subtrans


This conflicts with my two-phase commit patch. I'm using the fourth state
to mark transactions that have been prepared (1st. phase) but not yet
committed.
I think I can work around it in my code, so that you can have the fourth
state. I have to keep a list of prepared transactions in memory anyway, I
can use that instead.
He who commits first, wins :P

Chris

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Email addresses on developer bios site

[Christopher Kings-Lynne]

Is there any chance we could get our email addresses obfuscated to
prevent spam?
Just an FYI, but just by posting, you do realize that your email address
is propogated to every Usenet server in the world, as well as several
search engines like Google and Gname, right?
I'm well aware of that, since you, bruce and tom currently attempt to 
sell me Viagra several times a day... :)

Email harvesting developer.postgresql.org will give them one occurance of
your email address out of, most likely
, several million out there that it
could find :(
Ok...

Chris

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] Per database users/admins, handy for database virtual hosting...

[Sean Chittenden]

I've had to work through this and have with a series of messy tables 
and functions, but this screams a need for a more elegant solution.  
I've dug through the archives and didn't come up with a satisfying long 
term answer for virtual hosting beyond what I've already implemented.

Per cluster users is handy for the admins because I can create one 
account for me and not think about needing to create an account for 
every database in the cluster.  Per database users, on the other hand, 
is ideal for database virtual hosting, but is a PITA for DBA's who need 
to create accounts in every database in the cluster.  I haven't read 
much in the last few months, but archives from 2002 suggested there 
wasn't much on the table in terms of making this happen beyond adding a 
function that runs as a DBA to create users (which I've done).

What's the feasibility of augmenting the system catalogs so that 
something similar to the following is possible:

CREATE VIEW pg_catalog.pg_shadow AS
SELECT usename, usesysid, usecreatedb, usesuper,
usecatupd, passwd, valuntil, useconfig
FROM pg_catalog.pg_shadow_cluster
   UNION ALL
SELECT usename, usesysid, usecreatedb, usesuper,
usecatupd, passwd, valuntil, useconfig
FROM pg_catalog.pg_shadow_db;
And then set up RULEs to direct INSERTs, UPDATEs, DELETEs from 
pg_shadow to pg_shadow_db.  CREATE USER/ALTER USER operates on 
pg_catalog_db, then CREATE CLUSTER USER/ALTER CLUSTER USER operates on 
pg_catalog_cluster.

Tom, what do you think?  What other ideas do you have kicking around in 
your head?

*shrug*  Something for the TODO list and/or an inspired hacker.  -sc

--
Sean Chittenden
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Thomas Swan]

>
> On Mar 25, 2004, at 1:21, Neil Conway wrote:
>
>> I think the lack of good Win32 support (unless rectified before the
>> release of 7.5) is a pretty major problem with Arch -- that alone
>> might be sufficient to prevent us from adopting it.
>
>   I don't do Windows, but my understanding is that tla is as well
> supported on Windows as postgres is.
>

It that like the best beach volleball player in Antarctica?  The Windows
port of Postgresql is still in its infancy.  It's coming along, but its
not a finished product.


>   The design is fundamentally easy enough that a Windows user who cares
> could probably make a more suitable port for Windows than the UNIX guys
> are interested in making.  I've seen such discussions on the list.
>
> --
> Dustin Sallings
>
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
>


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Neil Conway]

On 25-Mar-04, at 3:03 PM, Dustin Sallings wrote:
	I don't do Windows, but my understanding is that tla is as well 
supported on Windows as postgres is.
David Wheeler disagrees:

A serious weakness of arch is that it doesn't work well on 
Windows-based systems, and it's not clear if that will ever change. 
There are ports of arch, both non-native (Cygwin and Services for Unix) 
and a native port too. However, the current win32 port is only in its 
early stages, and the Win32 page on the Arch wiki says "Arch was never 
intended to run on a non-POSIX system. Don't expect to have a full 
blown arch on your Microsoft computer." At least part of the problem is 
the long filenames used internally by arch; arch could certainly be 
modified to help, though there doesn't seem to be much movement in that 
direction. Other problematic areas include symbolic links, proper file 
permissions, and newline problems, as well as the general immaturity of 
the port as of March 2004. Some people don't think that poor Windows 
support is a problem; to me (and others!), that's a serious problem. 
Even if you don't use any Microsoft Windows systems, people don't want 
to use many different SCM systems, so if one can handle many 
environments and the other can't, people will use the one that can 
handle more environments. I think GNU Arch's use will be hampered by 
this lack of support as long as this is true, even for people who never 
use Windows; good native Windows support is very important for an SCM 
tool.

-Neil

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [PERFORM] [HACKERS] fsync method checking

[markw]

On 22 Mar, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
>> I could certainly do some testing if you want to see how DBT-2 does.
>> Just tell me what to do. ;)
> 
> Just do some runs that are identical except for the wal_sync_method
> setting.  Note that this should not have any impact on SELECT
> performance, only insert/update/delete performance.

Ok, here are the results I have from my 4-way xeon system, a 14 disk
volume for the log and a 52 disk volume for everything else:
http://developer.osdl.org/markw/pgsql/wal_sync_method.html

7.5devel-200403222  

wal_sync_method metric
default (fdatasync) 1935.28
fsync   1613.92

# ./test_fsync -f /opt/pgdb/dbt2/pg_xlog/test.out
Simple write timing:
write0.018787

Compare fsync times on write() and non-write() descriptor:
(If the times are similar, fsync() can sync data written
 on a different descriptor.)
write, fsync, close 13.057781
write, close, fsync 13.311313

Compare one o_sync write to two:
one 16k o_sync write 6.515122
two 8k o_sync writes12.455124

Compare file sync methods with one 8k write:
(o_dsync unavailable)  
open o_sync, write   6.270724
write, fdatasync13.275225
write, fsync,   13.359847

Compare file sync methods with 2 8k writes:
(o_dsync unavailable)  
open o_sync, write  12.479563
write, fdatasync13.651709
write, fsync,   14.000240

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] HEAD compile troubles

[Bruce Momjian]

David Fetter wrote:
> Kind people,
> 
> I just tried to compile HEAD on fedora, and it broke as per 
> 
> 
> Any ideas what i buggered up?

Fixed.  Not sure why I didn't see the problem because I do compile with
SSL.  Anyway, patch attached and applied.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073
Index: src/interfaces/libpq/libpq-int.h
===
RCS file: /cvsroot/pgsql-server/src/interfaces/libpq/libpq-int.h,v
retrieving revision 1.86
diff -c -c -r1.86 libpq-int.h
*** src/interfaces/libpq/libpq-int.h24 Mar 2004 03:45:00 -  1.86
--- src/interfaces/libpq/libpq-int.h25 Mar 2004 21:47:54 -
***
*** 458,463 
--- 458,466 
  #ifdef ENABLE_THREAD_SAFETY
  extern void check_sigpipe_handler(void);
  extern pthread_key_t thread_in_send;
+ #endif
+ 
+ #ifdef USE_SSL
  extern bool pq_initssllib;
  #endif
  

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Log rotation

[Bruce Momjian]

Robert Treat wrote:
> On Wednesday 24 March 2004 12:31, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> > > This thread seems to have died without a conclusion. AFAICS, we have 5
> > > options:
> > >
> > > . the apache program - see below
> > >   pro: robust, portable, extremely well tested, no effort to import
> > >   con: possible license issues, limited features
> > > . Peter Eisentraut's program
> > >   pro: portable, better featured, no license issues
> > >   con: code state uncertain, less well tested
> > > . the Afilias script
> > >   pro: well featured, no license issues
> > >   con: not portable (relies on perl), testing status uncertain
> > > . something new
> > >   pro: no license issues, can make as featured as desired, portable
> > >   con: lots of effort, untested
> > > . nothing
> > >   pro: no effort, no license issues :-)
> > >   con: feature is desired
> > >
> > > The issues seem to have been thrashed out ad nauseam. Surely we can put
> > > *something* in contrib for this? After all, nobody has to use it if they
> > > don't want to.
> >
> > Shouldn't all of these just be on gborg?
> 
> Some could simply be an article/guide on techdocs and/or a chapter in the 
> docs... "how to use postgresql with apache logrotate" for example

We already have an example of using logroate in the docs, right?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] HEAD compile troubles

[David Fetter]

On Thu, Mar 25, 2004 at 04:48:59PM -0500, Bruce Momjian wrote:
> David Fetter wrote:
> > Kind people,
> > 
> > I just tried to compile HEAD on fedora, and it broke as per
> > 
> > 
> > Any ideas what i buggered up?
> 
> Fixed.  Not sure why I didn't see the problem because I do compile
> with SSL.  Anyway, patch attached and applied.

Thanks!

Cheers,
D
-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] pg_advisor schema proof of concept

[Robert Treat]

On Thu, 2004-03-25 at 11:31, Fabien COELHO wrote:
> 
> > > Also, if they have a partial index on the FK, it's not good enough!  In
> > > CVS, IS NOT NULL partial indexes should be used, but in general all
> > > others still won't...
> >
> > Whoa, there, partner!   Keep in mind that there are *often* reasons for using
> > a partial index on an FK, or even no index at all!  The docs for pg_advisor
> > need to reflect that it only catches little details the developer might
> > otherwise have missed.   It's not smarter than a DBA.
> 
> Sure.
> 
> That's why advices are "graded" from info to error in the current
> preliminary version.
> 
> Advices that may or may not be good depending on undecidable elements
> have a lower grade. For instance, most attributes should be "NOT NULL"
> from a statistical point of view, but it is perfectly legitimate to
> have nullable attributes mostly anywhere, so the corresponding advices
> is just an "info".
> 

Are you planning on making some type of differentiation on advise that
is performance based rather than advise that is theory based?  I see
both cases being hinted at and it seems like a subtle but important
piece of information...

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Dustin Sallings]

On Mar 25, 2004, at 9:22, Magnus Naeslund(t) wrote:

> You can use distributed revision control systems as centralized
> systems, but not vice-versa.
>
Not true, the other way around exists, that is what svk does.
	From its description, svk sounds like a completely different system:

	``svk is a decentralized version control system written in Perl. It 
uses the subversion filesystem but provides some other powerful 
features.''

	I.e. it seems to have a CVS vs. RCS relationship.  It would be unfair 
to call CVS RCS.

--
Dustin Sallings
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Dustin Sallings]

On Mar 25, 2004, at 1:21, Neil Conway wrote:

I think the lack of good Win32 support (unless rectified before the 
release of 7.5) is a pretty major problem with Arch -- that alone 
might be sufficient to prevent us from adopting it.
	I don't do Windows, but my understanding is that tla is as well 
supported on Windows as postgres is.

	The design is fundamentally easy enough that a Windows user who cares 
could probably make a more suitable port for Windows than the UNIX guys 
are interested in making.  I've seen such discussions on the list.

--
Dustin Sallings
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Dustin Sallings]

On Mar 25, 2004, at 5:05, Jan Wieck wrote:

The difference here is that instead of submitting a patch for review, 
which is then frozen, the branch owner can (and that means some will, 
no matter what your intentions are) keep modifying the branch during 
the review process, other than just keeping it in sync with 
conflicting changes to the trunk. How do you plan to prevent that?
	You do both.  Changesets are immutable.  A patch cannot be modified.  
However, new patches can be added for tracking changes to the tree.  
You can review the original diff, and you can review how it's tracked 
head-of-line changes independently.  You can take the original diff and 
manually wedge it in if you want, or you can see how the latest 
progress differs before submission.

--
Dustin Sallings
---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] Nested transaction proposal - take N (N > 2)

[Heikki Linnakangas]

I haven't seen your patch yet, but the proposal looks good to me.

On Tue, 23 Mar 2004, Alvaro Herrera wrote:

> Let the currently unused fourth state in pg_clog indicate a
> committed subtransaction.  In pg_clog there are two bits per
> transaction, commit and abort, with the following meaning:
>
>  a  c
>  0  0  transaction in progress, the owning backend knows whether
>it is a main- or a sub-transaction, other backends don't care
>  1  0  aborted, nobody cares whether main- or sub-transaction
>  0  1  committed main-transaction or - with shortcut 2 - a sub-
>transaction that's known committed to all active transactions
>  1  1  committed sub-transaction, have to look for parent in
>pg_subtrans

This conflicts with my two-phase commit patch. I'm using the fourth state
to mark transactions that have been prepared (1st. phase) but not yet
committed.

I think I can work around it in my code, so that you can have the fourth
state. I have to keep a list of prepared transactions in memory anyway, I
can use that instead.

> Lock Management
> ---
>
> When a subtransaction aborts, it has to release all LWLocks and
> heavyweight locks it's currently holding.  On subtrans commit, all locks
> are held and reassigned to the parent transaction.  Only at main
> transaction commit are all locks released.

I have code for reassigning locks in my two-phase commit patch too. Locks
are reassigned to a special "nobody" pseudo-backend, when a transaction
prepares to commit. We might be able to share some code.

> File deletion, Deferred triggers, Asynchronous notifies
> 
>
> These mechanisms will have to keep lists of items corresponding to each
> subtransaction, and do something special to it on commit or on abort.
> Deftriggers and notifies can be dropped on transaction abort, which is
> very easy if we allocate them in the CommitContext.  On subtrans commit,
> the list of them is reassigned to the parent subtrans.
>
> File deletion is different because we can drop some files on
> subtransaction abort.  At commit, items are reassigned to parent.

I'm looking forward to see your solutions to these issues. I'm facing the
same problems, with the twist that transactions that have been prepared
for commit have to survive shutdowns.

- Heikki


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] [HACKERS] fsync method checking

[Josh Berkus]

Bruce,

> We don't actually extend the WAL file during writes (preallocated), and
> the access/modification timestamp is only in seconds, so I wonder of the
> OS only updates the inode once a second.  What else would change in the
> inode more frequently than once a second?

What about really big writes, when WAL files are getting added/recycled?

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [PERFORM] [HACKERS] fsync method checking

[Bruce Momjian]

[EMAIL PROTECTED] wrote:
> > I've made a test run that compares fsync and fdatasync: The performance 
> > was identical:
> > - with fdatasync:
> > 
> > http://khack.osdl.org/stp/290607/
> > 
> > - with fsync:
> > http://khack.osdl.org/stp/290483/
> > 
> > I don't understand why. Mark - is there a battery backed write cache in 
> > the raid controller, or something similar that might skew the results? 
> > The test generates quite a lot of wal traffic - around 1.5 MB/sec. 
> > Perhaps the writes are so large that the added overhead of syncing the 
> > inode is not noticable?
> > Is the pg_xlog directory on a seperate drive?
> > 
> > Btw, it's possible to request such tests through the web-interface, see
> > http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html
> 
> We have 2 Adaptec 2200s controllers, without the battery backed add-on,
> connected to four 10-disk arrays in those systems.  I can't think of
> anything off hand that would skew the results.
> 
> The pg_xlog directory is not on a separate drive.  I haven't found the
> best way to lay out of the drives on those systems yet, so I just have
> everything on a 28 drive lvm2 volume.

We don't actually extend the WAL file during writes (preallocated), and
the access/modification timestamp is only in seconds, so I wonder of the
OS only updates the inode once a second.  What else would change in the
inode more frequently than once a second?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
  joining column's datatypes do not match

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Magnus Naeslund(t)]

Dustin Sallings wrote:

>
> You can use distributed revision control systems as centralized
> systems, but not vice-versa.
>
Not true, the other way around exists, that is what svk does.

> As far as understanding the simplicity of arch (if you wanted to
> understand the problems it solves and implement it yourself), a really
> good presentation was posted today to the arch list that sums it up
> quickly and concisely.  It's hard to go through that and not think, ``I
> could write this.''
>
> http://web.verbum.org/tla/grokking-arch/grokking-arch.html
>
Will read it, thanks.

Regards,
Magnus
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] [HACKERS] fsync method checking

[markw]

On 25 Mar, Manfred Spraul wrote:
> Tom Lane wrote:
> 
>>[EMAIL PROTECTED] writes:
>>  
>>
>>>I could certainly do some testing if you want to see how DBT-2 does.
>>>Just tell me what to do. ;)
>>>
>>>
>>
>>Just do some runs that are identical except for the wal_sync_method
>>setting.  Note that this should not have any impact on SELECT
>>performance, only insert/update/delete performance.
>>  
>>
> I've made a test run that compares fsync and fdatasync: The performance 
> was identical:
> - with fdatasync:
> 
> http://khack.osdl.org/stp/290607/
> 
> - with fsync:
> http://khack.osdl.org/stp/290483/
> 
> I don't understand why. Mark - is there a battery backed write cache in 
> the raid controller, or something similar that might skew the results? 
> The test generates quite a lot of wal traffic - around 1.5 MB/sec. 
> Perhaps the writes are so large that the added overhead of syncing the 
> inode is not noticable?
> Is the pg_xlog directory on a seperate drive?
> 
> Btw, it's possible to request such tests through the web-interface, see
> http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html

We have 2 Adaptec 2200s controllers, without the battery backed add-on,
connected to four 10-disk arrays in those systems.  I can't think of
anything off hand that would skew the results.

The pg_xlog directory is not on a separate drive.  I haven't found the
best way to lay out of the drives on those systems yet, so I just have
everything on a 28 drive lvm2 volume.

Mark

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Email addresses on developer bios site

[Devrim GUNDUZ]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

On Thu, 25 Mar 2004, Christopher Kings-Lynne wrote:

> On this page:
> 
> http://developer.postgresql.org/bios.php
> 
> Is there any chance we could get our email addresses obfuscated to 
> prevent spam?

Ok, done.

Regards,
- -- 
Devrim GUNDUZ  
[EMAIL PROTECTED]   [EMAIL PROTECTED] 
http://www.TDMSoft.com
http://www.gunduz.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAYxMXtl86P3SPfQ4RAiSPAKCOpJEyv1nAqAkawaJEX+tvAHGrhQCg3BSR
FdA309RpG28i0N0zchGGask=
=txzg
-END PGP SIGNATURE-


---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] pg_advisor schema proof of concept

[Fabien COELHO]

> > Also, if they have a partial index on the FK, it's not good enough!  In
> > CVS, IS NOT NULL partial indexes should be used, but in general all
> > others still won't...
>
> Whoa, there, partner!   Keep in mind that there are *often* reasons for using
> a partial index on an FK, or even no index at all!  The docs for pg_advisor
> need to reflect that it only catches little details the developer might
> otherwise have missed.   It's not smarter than a DBA.

Sure.

That's why advices are "graded" from info to error in the current
preliminary version.

Advices that may or may not be good depending on undecidable elements
have a lower grade. For instance, most attributes should be "NOT NULL"
from a statistical point of view, but it is perfectly legitimate to
have nullable attributes mostly anywhere, so the corresponding advices
is just an "info".

-- 
Fabien Coelho - [EMAIL PROTECTED]

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] pg_advisor schema proof of concept

[Josh Berkus]

Fabien, Christopher:

It would be nice for pgAdmin & PhpPgAdmin to have GUI interfaces to 
pg_advisor, though.

Also, I would argue for this to be a GBorg/pgFoundry project rather than part 
of the core.  It's the sort of thing that could easily be database-version 
agnostic, and that SQL jockeys who are not Hackers could contribute to.

> Also, if they have a partial index on the FK, it's not good enough!  In
> CVS, IS NOT NULL partial indexes should be used, but in general all
> others still won't...

Whoa, there, partner!   Keep in mind that there are *often* reasons for using 
a partial index on an FK, or even no index at all!  The docs for pg_advisor 
need to reflect that it only catches little details the developer might 
otherwise have missed.   It's not smarter than a DBA.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

---(end of broadcast)---
TIP 8: explain analyze is your friend

Re: [HACKERS] < operator for user-defined types

[Tom Lane]

Teodor Sigaev <[EMAIL PROTECTED]> writes:
> So, I must declare b-tree opclass for tsvector. Why?
> My supposition is to guarantee that operator < is really 'less-than'
> one. Is it?

Exactly.  We used to assume that any operator named '<' would be
suitable for sorting, but it's a lot safer to assume that an operator
associated with a b-tree opclass behaves in the right way.  Also there
are some optimizations possible as a result.  (It turns out that the
sorting code will end up using the comparison support function for the
opclass, and not the operator per se, because that way we only need one
function call per comparison.  Using the operator, we'd often need two
calls.)

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Email addresses on developer bios site

[Marc G. Fournier]

On Thu, 25 Mar 2004, Christopher Kings-Lynne wrote:

> On this page:
>
> http://developer.postgresql.org/bios.php
>
> Is there any chance we could get our email addresses obfuscated to
> prevent spam?

Just an FYI, but just by posting, you do realize that your email address
is propogated to every Usenet server in the world, as well as several
search engines like Google and Gname, right?

Email harvesting developer.postgresql.org will give them one occurance of
your email address out of, most likely, several million out there that it
could find :(


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html

Re: [HACKERS] Log rotation

[Robert Treat]

On Wednesday 24 March 2004 12:31, Bruce Momjian wrote:
> Andrew Dunstan wrote:
> > This thread seems to have died without a conclusion. AFAICS, we have 5
> > options:
> >
> > . the apache program - see below
> >   pro: robust, portable, extremely well tested, no effort to import
> >   con: possible license issues, limited features
> > . Peter Eisentraut's program
> >   pro: portable, better featured, no license issues
> >   con: code state uncertain, less well tested
> > . the Afilias script
> >   pro: well featured, no license issues
> >   con: not portable (relies on perl), testing status uncertain
> > . something new
> >   pro: no license issues, can make as featured as desired, portable
> >   con: lots of effort, untested
> > . nothing
> >   pro: no effort, no license issues :-)
> >   con: feature is desired
> >
> > The issues seem to have been thrashed out ad nauseam. Surely we can put
> > *something* in contrib for this? After all, nobody has to use it if they
> > don't want to.
>
> Shouldn't all of these just be on gborg?

Some could simply be an article/guide on techdocs and/or a chapter in the 
docs... "how to use postgresql with apache logrotate" for example

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[HACKERS] < operator for user-defined types

[Teodor Sigaev]

I got several suggestions to include ordering operator for tsvector to aim 
grouping, union and except etc.

I wrote silly comparing function (byte to byte with some optimizations), but I 
wondered that for using operator < in order clause its need to declate B-tree 
opclass for type:

regression=# select  a from test_tsvector order by a;
ERROR:  could not identify an ordering operator for type tsvector
HINT:  Use an explicit ordering operator or modify the query.
I see in
backend/utils/cache/typcache.c near line 169:
if ((flags & TYPECACHE_LT_OPR) && typentry->lt_opr == InvalidOid)
{
if (typentry->btree_opc != InvalidOid)
typentry->lt_opr = 
get_opclass_member(typentry->btree_opc,InvalidOid, BTLessStrategyNumber);
}

So, I must declare b-tree opclass for tsvector. Why?
My supposition is to guarantee that operator < is really 'less-than' one. Is it?


--
Teodor Sigaev  E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Alvaro Herrera]

On Thu, Mar 25, 2004 at 08:05:05AM -0500, Jan Wieck wrote:

> The difference here is that instead of submitting a patch for review, 
> which is then frozen, the branch owner can (and that means some will, no 
> matter what your intentions are) keep modifying the branch during the 
> review process, other than just keeping it in sync with conflicting 
> changes to the trunk. How do you plan to prevent that?

I think it's much better for the reviewer to be able to see the history
of changes of the patch (branch), without having to look at the whole
patch again every time a small change is made to it.

Or do you diff two versions of a patch to see if the author only changed
what he says he changed?  Wow, a diff of a diff, _that_ should be
difficult to read.

-- 
Alvaro Herrera ()
"Use it up, wear it out, make it do, or do without"

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Andrew Dunstan]

Neil Conway said:

> I don't think anything mentioned in this thread so far would be an
> enormous improvement over what we have now. However, I am still open to
>  trying Arch or SVN: in the long run, I think the productivity gain
> from  even an incremental improvement in the development toolset is
> worth a  little effort in relearning and migration.
>

ISTM what we have here is a solution in search of a problem. When the
committers tell us that there is a problem we should start looking.


> But as I said, I don't think it's a critical issue, and if other
> developers would rather we stick with what we have, that's fine with
> me.
>

Maybe we should look at providing SVN as a project option on the new
PGFoundry. That might let at least a part of the community get its toes
wet with it, without disrupting the core in the first instance.

>
> I think the lack of good Win32 support (unless rectified before the
> release of 7.5) is a pretty major problem with Arch -- that alone might
>  be sufficient to prevent us from adopting it.
>

Agreed. It's a killer from my POV.

cheers

andrew



---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Jan Wieck]

Dustin Sallings wrote:

On Mar 24, 2004, at 20:29, Tom Lane wrote:

Not here.  You want me to trust some bit of code (with absolutely zero
understanding of the source text it's hacking on) to figure out how to
resolve conflicting patches?  That sounds like a recipe for big-time
unhappiness.
	The idea is that it's the responsibility of the branch owner to keep 
it up-to-date.  For example, I've got a branch of tla (an arch 
implementation) I made soon after I started using it in order to add a 
command I wanted and refactor a bit of the insides.  Over time, a lot 
of stuff has changed, but I still want my stuff to work, so as I update 
my branch against head of line, I make minor changes to it as things 
go.

	The difference is that instead of having a patch sitting in a queue 
somewhere suffering from bit-rot, you've got a pointer to a branch that 
you can merge when you get around to it.  You can still view it as a 
diff if you want, but the diff you get six months after the original 
submission may be quite a bit different from what you would've got at 
the beginning if a lot of the code around it has changed.
The difference here is that instead of submitting a patch for review, 
which is then frozen, the branch owner can (and that means some will, no 
matter what your intentions are) keep modifying the branch during the 
review process, other than just keeping it in sync with conflicting 
changes to the trunk. How do you plan to prevent that?

Jan

--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: [HACKERS] Avoid MVCC using exclusive lock possible?

[Yves Darmaillac]

Andrew Sullivan a écrit :

On Sun, Feb 29, 2004 at 10:43:34AM -0500, Tom Lane wrote:
 

general I think our VACUUM-based approach is superior to the
Oracle-style UNDO approach, because it pushes the maintenance overhead
out of foreground transaction processing and into a schedulable
background process.  Certainly any Oracle DBA will tell you that huge
   

I completely agree with this.  If the recent work on lowering the
overall cost ov VACUUM on loaded systems pays off, then I think there
can be no argument that the work-now, vacuum-later strategy is the
best approach, simply because it deals with the outlying and
unexpected cases better than the alternatives.  I know too many
people who have been burned by running out of rollback segments when
some use pattern emerged that they hadn't planned for.
A

I agree too. The VACUUM aproach is better as it reduces fragmentation 
and chained rows due to columns size change.



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] pg_advisor schema proof of concept

[Andreas Pflug]

Christopher Kings-Lynne wrote:

(6) possible inclusion in postgresql?
 - among other contributions? what about contrib/advisor?
 - added to template1 on default installation?
   maybe not for a first release? or yes? it is easier to communicate
   about


I think we're going to want a gborg project for 
developing/coordinating tests anyway. Having the schema included in 
contrib/ might help adoption, but so would pgadmin/phpgadmin. Any 
client-builders reading this? What do you think?


Both phpPgAdmin (me) and the pgAdmin team have added or have thought 
about adding some 'schema analysis' features to our products.  If 
pg_advisor is available, I certainly won't bother and I will just 
recommend to people that they install it.

I think it probably should live in userland...
Yeah, this should live in userland.
Maybe this could be implemented as set of some descriptions, which is 
interpreted by a standalone tool, or interpreted by the gui tools 
available. This way, we could include a set of them into the admin tool 
distributions, ensuring a basic set is noticed by the admins (subject to 
update from contrib).

Currently, a check for old style fk triggers is hard-coded into pgadmin3 
(to detect missing adddepend), because fk triggers are considered 
internal and thus suppressed.

There are plans (and basic work) for a FK index tool, which wouldn't be 
obsolete if a pg_advisor would detect it because it's intended to have a 
checkbox "fix this" in the list of detected fks.

Regards,
Andreas


---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: subversion vs cvs (Was: Re: [HACKERS] linked list rewrite)

[Neil Conway]

On 25-Mar-04, at 12:25 AM, Dustin Sallings wrote:
	It's definitely not a magic tool that makes bad code good and 
conflicting patches happy.  It solves other problems, though.
I don't think anything mentioned in this thread so far would be an 
enormous improvement over what we have now. However, I am still open to 
trying Arch or SVN: in the long run, I think the productivity gain from 
even an incremental improvement in the development toolset is worth a 
little effort in relearning and migration.

But as I said, I don't think it's a critical issue, and if other 
developers would rather we stick with what we have, that's fine with 
me.

WRT the relative merits of CVS, Arch, and SVN, David Wheeler (of 
Bricolage) has written an interesting article comparing the three 
systems:

http://www.dwheeler.com/essays/scm.html

I think the lack of good Win32 support (unless rectified before the 
release of 7.5) is a pretty major problem with Arch -- that alone might 
be sufficient to prevent us from adopting it.

-Neil

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings