Обсуждение: BTW, if anyone wants to work on it...

Поиск
Список
Период
Сортировка

BTW, if anyone wants to work on it...

От
Tom Lane
Дата:
We've had a couple of cases recently where we had to advise DBAs to make
manual changes in the system catalogs --- see for instance the 7.4.2
release notes or
http://archives.postgresql.org/pgsql-announce/2005-05/msg00001.php

It'd be nicer if this sort of thing could be handled automatically
by a software update.  There are good reasons why it's not trivial,
but having been burnt twice in recent memory, I'm starting to think
it'd be worth setting up a mechanism to handle such changes
automatically.  Anyone up for working on it?
        regards, tom lane


Re: BTW, if anyone wants to work on it...

От
"Magnus Hagander"
Дата:
> We've had a couple of cases recently where we had to advise
> DBAs to make manual changes in the system catalogs --- see
> for instance the 7.4.2 release notes or
> http://archives.postgresql.org/pgsql-announce/2005-05/msg00001.php
>
> It'd be nicer if this sort of thing could be handled
> automatically by a software update.  There are good reasons
> why it's not trivial, but having been burnt twice in recent
> memory, I'm starting to think it'd be worth setting up a
> mechanism to handle such changes automatically.  Anyone up
> for working on it?

I suppose you want something a bit less trivial than this one, but if
somebody has benefit from it, here's the script I've been using to patch
my dbs. It's very trivial - error checking is dba-eyeballs, for example.
But if there are lots of databases, at least it saves a few steps.

A more complete solution would of course require some better error
checking ;-)

//Magnus

Вложения

Re: BTW, if anyone wants to work on it...

От
Manfred Koizar
Дата:
On Tue, 03 May 2005 02:45:09 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm starting to think
>it'd be worth setting up a mechanism to handle such changes
>automatically.

I've been using this skeleton for quite some time now.  Magnus'
    psql ... | while read D
might be more robust than my
    for db in `enumdatabases`

Servus
 Manfred

Вложения