[ On Wednesday, November 12, 2003 at 07:22:55 (+0100), Michal Pasternak wrote: ]
> Subject: Re: hier(7) silent on pkg documentation
>
> Greg A. Woods [Mon, Nov 10, 2003 at 03:29:39PM -0500]:
> > > Most intuituve path for postgresql-docs IMO would be
> > > share/doc/postgresql/guide.
> > 
> > Why the "/guide" suffix?  How is that intuitive?
> 
> Because PostgreSQL docs are located in "postgresql", and PostgreSQL Guide is
> located in "postgresql/guide". For example: would you rather like to have
> those 24 HTML files of NetBSD guide available separatley in
> /usr/share/doc/guide - or freely floating somewhere in /usr/share/doc ?

Well then the most intuitive patth for postgresql documentation would be
"$PREFIX/share/doc/posgresql".   I.e. the "/guide" is not part of the
picture.  If the documentation happens to be best organized such that
there's a "guide" sub-directory then that's fine -- but that
sub-directory is not part of the ``most intuitive path.''

> You don't have to dump the databases on recent PgSQL. I haven't tested it,
> but PgSQL developers claimed binary compatibility of the database files some
> time ago.

I'll never trust that enough for production use -- and it's not likely
to always be true in any case.  I still want to be able to test the new
version against the production database files before de-installing the
old version.  I trust binary packages a lot more than I used to but with
a long-running critical database server in a 24x7 production environment
it's still safer not to de-install production software before the new
replacement version is in place and proven ready to work properly.  It's
simply good engineering practice, something that cannot be ignored when
production lines or critical services infrastructure depends on the
full-time operation of the database server.

There might someday be a binary conversion utility should pgsql ever
change binary formats, just like "fsck_ffs -c N" for example, but using
it would still require downtime equal to the time to do the conversion,
unless you can install both versions simultaneously, copy the
binary-opaque database files, convert the copies, and test the result
before switching over.  (and what if the conversion fails and corrupts
your database?)

I.e. the only way to do a safe switch of a production database with
downtime limited only to the time it takes to restart the server
processes, is if you can install and test the new version simultaneously
with the old version running in production, on the same machine.

Testing the new version on a second machine, even with a manually copied
database, may still miss testing true production environment features
critical to full operation.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>