Rob Sargentg wrote:
Not clear to me why an
individual dev box needs to be that current data-wise.
It's significantly easier to debug a production problem when you can
duplicate the problem on your local machine. Hey, when I go to JennyC's
activity page and scroll down three times, I see
Greg Sabino Mullane wrote:
update pg_database set datallowconn = false where datname = 'foobar';
That's perfect - thanks. Now I can (I think) do this:
pg_restore -d rails_dev_new
[wait]
psql template1
update pg_database set datallowconn = false where datname = 'rails_dev';
select
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jay Levitt spoke:
Greg Sabino Mullane wrote:
update pg_database set datallowconn = false where datname = 'foobar';
That's perfect - thanks. Now I can (I think) do this:
pg_restore -d rails_dev_new
[wait]
psql template1
update
Our development workstations maintain a local copy of the production
database (which has been small enough that this is workable right now, and
preferable to having a test database with generated fake data). We've been
doing this by rsync'ing a compressed pgdump from the production server,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
1. How can I prevent (or redirect, or timeout, or anything) new connections?
I think superuser roles might be exempt from connection limits and
privileges. I could repeatedly terminate backends until I'm able to rename
the database,
On 01/01/2012 11:51 AM, Jay Levitt wrote:
revoke connect on database rails_dev from public;
select pg_terminate_backend(procpid) from pg_stat_activity where
datname='rails_dev';
Still, the app can reconnect. (So can psql.)
So...
1. How can I prevent (or redirect, or timeout, or anything)
