Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> ... On top of that, that's also the risk of someone being a
>> superuser. They will ALWAYS have the power to hose things. Period. As
>> such, I don't consider that to be a valid argument.
> That was my feeling too. If you can't trust the other admins, it is
> hard for us to trust them either.
Sigh. It's not about trust: it's about whether pg_upgrade can enforce
or at least check its assumptions. I don't feel that it's a
production-grade tool as long as it has to cross its fingers that the
DBA made no mistakes.
Also, if the previous example had no impact on you, try this one:
$ postmaster -N 1 -c superuser_reserved_connections=0 &
pg_dump: [archiver (db)] connection to database "regression" failed: FATAL: Sorry, too many clients already
pg_dumpall: pg_dump failed on regression, exiting
-N 1 *will* cause problems.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Lamar Owen||Date: 2003-01-06 04:04:59|
|Subject: Re: Upgrading rant.|
|Previous:||From: Tom Lane||Date: 2003-01-06 03:40:46|
|Subject: Re: AclId is defined in the wrong place |