PostgreSQL: soltar la base de datos PostgreSQL a través de la línea de comandos [cerrado]

321

Estoy tratando de soltar mi base de datos y crear una nueva a través de la línea de comando.

Me conecto usando psql -U usernamey luego hago un \connect template1, seguido de a DROP DATABASE databasename;.

Me sale el error

otros usuarios acceden a la base de datos de base de datos

Apagué Apache e intenté esto nuevamente, pero aún recibo este error. ¿Estoy haciendo algo mal?

database postgresql

— iman453
fuente

2

¿Qué sucede si solo ejecuta el dropdb databasenamecomando desde la línea de comando?

— Dylan Markow

1

Dice "ERROR: no se puede eliminar la base de datos abierta actualmente"

— iman453

44

Uso psql -U <user> -c "drop database protodb"(sin nombre de base de datos)

— usuario

3

Esto reiniciará postgres y desconectará a todos: sudo service postgresql restart Luego haga un: dropdb -h localhost -p 5432 -U "youruser" "testdb" Observe el "" para asegurarse de que los caracteres especiales entren sin problemas.

— Unom

drop database <dataabase_name>;No olvides la coma.

— Sandip Subedi

455

Puede ejecutar el comando dropdb desde la línea de comando:

dropdb 'database name'

Tenga en cuenta que debe ser un superusuario o el propietario de la base de datos para poder eliminarlo.

También puede verificar la vista pg_stat_activity para ver qué tipo de actividad se está llevando a cabo actualmente en su base de datos, incluidos todos los procesos inactivos.

SELECT * FROM pg_stat_activity WHERE datname='database name';

— csano
fuente

3

Estoy usando el dropusercomando para eliminar también al usuario.

— pl1nk

66

Respuesta no útil en cuanto a la versión 9. El error sobre las conexiones abiertas sigue apareciendo.

— Pavel Vlasov

44

Esto reiniciará postgres y desconectará a todos: sudo service postgresql restart Luego haga un: dropdb -h localhost -p 5432 -U "youruser" "testdb" Observe el "" para asegurarse de que los caracteres especiales entren sin problemas.

— Unom

1

utilizando el usuario de postgres: sudo -u postgres dropdb 'nombre de base de datos'

— leszek.hanusz

\lpara ver todas las bases de datos que tienes.

— Sandip Subedi

115

Esto funcionó para mí:

select pg_terminate_backend(pid) from pg_stat_activity where datname='YourDatabase';

para postgresql anterior a 9.2 reemplace pidconprocpid

DROP DATABASE "YourDatabase";

http://blog.gahooa.com/2010/11/03/how-to-force-drop-a-postgresql-database-by-killing-off-connection-processes/

— Eugene
fuente

12

Tuve que cambiarlo un poco para que funcione:select pg_terminate_backend(pid) from pg_stat_activity where datname='YourDatabase';

— mrt

column "procpid" does not existpara la instancia de Amazon RDS postgres 9.6

— anon58192932

Hm. Ejecuté esto, pero se volvió a conectar inmediatamente, después de decir: "La conexión SSL se cerró inesperadamente [...] al intentar restablecer: se realizó correctamente". Annnd, estoy de vuelta.

— mlissner

67

Prueba esto. Tenga en cuenta que no hay una base de datos especificada, simplemente se ejecuta "en el servidor"

psql -U postgres -c "drop database databasename"

Si eso no funciona, he visto un problema con postgres reteniendo declaraciones preparadas huérfanas.
Para limpiarlos, haga esto:

SELECT * FROM pg_prepared_xacts;

entonces para cada identificación que vea, ejecute esto:

ROLLBACK PREPARED '<id>';

— Bohemio
fuente

Lo siento, soy nuevo en las bases de datos, así que esta es probablemente una pregunta estúpida, pero ¿dónde escribo esto? Antes de iniciar sesión en la base de datos, ¿verdad? Y debería reemplazar databasename con el nombre de mi base de datos, ¿verdad?

— iman453

@ iman453: Lo ejecutarías directamente desde tu shell / línea de comandos.

— mu es demasiado corto el

2

No existen cosas como "solo en el servidor" para postgresql. Debes conectarte a una base de datos. En este caso, se conectará a la base de datos de Postgres que está allí solo para casos como este. Y un buen punto sobre las transacciones preparadas, pero en ese caso debería recibir un mensaje de error que indique que ese es el problema.

— Scott Marlowe

1

Lo siento Bohemian, pero tú eres el que está equivocado. Aquí está pg_stat_activity mientras se ejecuta createdb desde la línea de comando: postgres = # select * from pg_stat_activity; 11564 | postgres | 22223 | 16384 | smarlowe | Prueba CREATE DATABASE; El | f | 2011-08-19 16: 18: 26.918933-06 | 2011-08-19 16: 18: 26.918933-06 | 2011-08-19 16: 18: 26.916578-06 | El | -1 Tenga en cuenta que esto sucede mientras se ejecuta createdb desde la línea de comando en otro terminal. Ese primer campo es el db al que estaba conectado mi script createdb

— Scott Marlowe

1

¿Por qué no es esta la respuesta número uno?

— Henley Chiu

16

Cuando dice que los usuarios están conectados, ¿qué hace la consulta "select * from pg_stat_activity;" ¿decir? ¿Están ahora conectados los demás usuarios además de usted? Si es así, es posible que deba editar su archivo pg_hba.conf para rechazar las conexiones de otros usuarios, o cerrar cualquier aplicación que esté accediendo a la base de datos pg para poder soltarla. Tengo este problema en ocasiones en producción. Establezca pg_hba.conf para tener dos líneas como esta:

local   all         all                               ident
host    all         all         127.0.0.1/32          reject

y decirle a pgsql que vuelva a cargar o reiniciar (es decir, sudo /etc/init.d/postgresql reload o pg_ctl reload) y ahora la única forma de conectarse a su máquina es a través de enchufes locales. Supongo que estás en Linux. Si no es así, es posible que deba ajustarse a algo que no sea local / ident en esa primera línea, a algo como host ... su nombre de usuario.

Ahora deberías poder hacer:

psql postgres
drop database mydatabase;

— Scott Marlowe
fuente