Re: Upgrading rant.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Greg Copeland <greg@copelandconsulting.net>, Oliver Elphick <olly@lfix.co.uk>, Hannu Krosing <hannu@tm.ee>, mlw <pgsql@mohawksoft.com>, Lamar Owen <lamar.owen@wgcr.org>, PostgresSQL Hackers Mailing List <pgsql-hackers@postgresql.org>
Date: 2003-01-06T03:56:13Z
Lists: pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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_dumpall 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