On PostgreSQL 9.6.6, running on Amazon RDS
SELECT * FROM pg_stat_activity WHERE datname = 'my_db'
yields nothing.
However, trying to drop the database
DROP DATABASE my_db;
fails with:
ERROR: database "my_db" is being accessed by other users DETAIL:
There are 3 other sessions using the database.
I've tried to lock down the number of conns to the db with these two three:
REVOKE CONNECT ON DATABASE my_db FROM public;
ALTER DATABASE my_db CONNECTION LIMIT 0;
ALTER DATABASE my_db WITH ALLOW_CONNECTIONS false;
I do have read replication set up (however — this shouldn't block as this is reading off the WAL?) and occasional snapshotting (not during the DROP stmt is being run though).
What are these three lingering conns and how do I get rid of them?
Related
I'm a bit confused about why I can't drop my database, so after connecting to my rds postgres instance with
psql --host=mu_user.amazonaws.com --port=5432 --username=my_user --password --dbname=postgres
I've REVOKED new connection to the db I want to drop with
REVOKE CONNECT ON DATABASE mydb FROM public;
then I have terminated all connection with
SELECT pid, pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'mydb' AND pid <> pg_backend_pid();
after that when I want to drop the db I still can't because It will say
ERROR: database "mydb" is being accessed by other users
DETAIL: There are 10 other sessions using the database.
If I inspect live connections with
SELECT
pid
,datname
,usename
,application_name
,client_hostname
,client_port
,backend_start
,query_start
,query
,state
FROM pg_stat_activity
WHERE state = 'active';
there will be none, but if I change active to idle I can see a bunch, and after trying to kill them with pg_terminate_backend(pid) I again can't drop the db and I again have the same ERROR, so can someone please help me understand what I'm I doing wrong here?
Those connections which are idle and always appearing are by my_user, who is also a superuser.
The problem is that those other connections are by a superuser, and superusers are exempt from permission checks, so revoking the CONNECT privilege on the database won't keep these guys out.
You could either block the connections via pg_hba.conf, or you can run both statements immediately after each other:
SELECT pg_terminate_backend(pid) FROM pg_stat_activity; DROP DATABASE mydb;
in the hope that the users won't have time to reconnect before the DROP DATABASE hits.
I am running through some very basic tests to confirm a backup/restore process is working on a local environment.
the issue I am running into is that it doesn't look as though pg_dump/pg_restore/psql is restoring a database to the same state.
A sample of what I am doing below from start to finish.
CREATE DATABASE testdb WITH ENCODING='UTF8' CONNECTION LIMIT=-1;
CREATE TABLE a
(
a INT
);
INSERT INTO a(a)
SELECT 1 UNION ALL
SELECT 2;
SELECT * FROM a;
GRANT ALL PRIVILEGES ON DATABASE testdb TO testuser;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO testuser;
Then running the pg_dump
pg_dump -Fc -v --host=localhost --username=postgres --dbname=testdb -f C:\test\testdb.dump
creating a side by side restore for this example
CREATE DATABASE testdb_restore WITH ENCODING='UTF8' CONNECTION LIMIT=-1;
pg_restore -v --host=localhost --username=postgres --dbname=testdb_restore C:\test\testdb.dump
Now when I right click on testdb in pgadmin and click "Create Script" I get the following
-- Database: testdb
-- DROP DATABASE testdb;
CREATE DATABASE testdb
WITH
OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'English_Australia.1252'
LC_CTYPE = 'English_Australia.1252'
TABLESPACE = pg_default
CONNECTION LIMIT = -1;
GRANT ALL ON DATABASE testdb TO postgres;
GRANT TEMPORARY, CONNECT ON DATABASE testdb TO PUBLIC;
GRANT ALL ON DATABASE testdb TO testuser;
When I click on the perform the same on testdb_restore, I get the following
-- Database: testdb_restore
-- DROP DATABASE testdb_restore;
CREATE DATABASE testdb_restore
WITH
OWNER = postgres
ENCODING = 'UTF8'
LC_COLLATE = 'English_Australia.1252'
LC_CTYPE = 'English_Australia.1252'
TABLESPACE = pg_default
CONNECTION LIMIT = -1;
As you can see I am missing the extra privileges from the original database.
I'm sure this is a very simple thing but I am currently lost on this one. I have also tried using methods and also pg_dump create database option added in and no difference.
Please note: I am extremely new to postgres and coming from a SQL Server background.
Roles and permissions are stored and managed per cluster, not per database, which is why pg_dump is not dumping them. You should use pg_dumpall if you are happy to have a dump of the whole cluster.
Alternatively, you can use pg_dumpall -r to dump roles only, and then pg_dump your database, and apply both scripts.
Unfortunately the privileges for a database are not included in a pg_dump. You'd have to use pg_dumpall for that, but that dumps all databases.
I know this is annoying. It is a bug of long standing that nobody has fixed yet.
I am having an issue with pg_restore --clean not clearing the database.
Or do I misunderstand what the --clean does, I am expecting it to truncate the database tables and reinitialize the indexes/primary keys.
I am using 9.5 on rds
This is the full command we use
pg_restore --verbose --clean --no-acl --no-owner -h localhost -U superuser -d mydatabase backup.dump
Basically what is happening is this.
I do a nightly backup of my production db, and restore it to an analytics db for the analyst to churn and run their reports.
I found out recently that the rails application used to view the reports was complaining that the primary keys were missing from the restored analytics database.
So I started investigating the production db, the analytics db etc. Which was when I realized that multiple rows with the same primary key existed in the analytics database.
I ran a few short experiments and realized that every time the pg_restore script is run it inserts duplicate data into the tables, this leads me to think that the --clean is not dropping and restoring the data. Because if I were to drop the schema beforehand, I don't get duplicate data.
To remove all tables from a database (but keep the database itself), you have two options.
Option 1: Drop the entire schema
You will need to re-create the schema and its permissions. This is usually good enough for development machines only.
DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
GRANT ALL ON SCHEMA public TO postgres;
GRANT ALL ON SCHEMA public TO public;
Applications usually use the "public" schema. You may encounter other schema names when working with a (legacy) application's database.
Note that for Rails applications, dropping and recreating the database itself is usually fine in development. You can use bin/rake db:drop db:create for that.
Option 2: Drop each table individually
Prefer this for production or staging servers. Permissions may be managed by your operations team, and you do not want to be the one who messed up permissions on a shared database cluster.
The following SQL code will find all table names and execute a DROP TABLE statement for each.
DO $$ DECLARE
r RECORD;
BEGIN
FOR r IN (SELECT tablename FROM pg_tables WHERE schemaname = current_schema()) LOOP
EXECUTE 'DROP TABLE IF EXISTS ' || quote_ident(r.tablename) || ' CASCADE'; -- DROP TABLE IF EXISTS instead DROP TABLE - thanks for the clarification Yaroslav Schekin
END LOOP;
END $$;
Original:
https://makandracards.com/makandra/62111-how-to-drop-all-tables-in-postgresql
I'm trying to drop the database I'm currently connected to like so, but I'm getting this error:
pq: cannot drop the currently open database
I don't really understand how I'm expected to drop the database if I have to close my connection, because then I don't think I will be able to use dbConn.Exec to execute my DROP DATABASE statement?
dbConn *sql.DB
func stuff() error {
_, err := dbConn.Exec(fmt.Sprintf(`DROP DATABASE %s;`, dbName))
if err != nil {
return err
}
return dbConn.Close()
}
I guess I could connect to a different database and then execute it on that connection, but I'm not even sure if that'd work, and it seems really weird to have to connect to a new database just to drop a different database. Any ideas? Thanks.
Because, you are trying to execute dropDb command on database, to which you have open connection.
According to postgres documentation:
You cannot be connected to the database you are about to remove. Instead, connect to template1 or any other database and run this command again.
This makes sense, because when you drop the entire database, all the open connection referencing to that database becomes invalid, So the recommended approach is to connect to different database, and execute this command again.
If you are facing a situation, where a different client is connected to the database, and you really want to drop the database, you can forcibly disconnect all the client from that particular database.
For example, to forcibly disconnect all clients from database mydb:
If PostgreSQL < 9.2
SELECT pg_terminate_backend(procpid) FROM pg_stat_activity WHERE datname = 'mydb';
Else
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'mydb';
Note: This command requires superuser privileges.
Then, you can connect to different database, and run dropDb command again.
If you encounter this problem in IntelliJ, change the schema with the following dropdown to postgres.
After that, I was able to drop a db.
I am using PostgreSQL 12 and pgAdmin-4 in Windows 10. I had to use a combination of the above answers to drop a database, which I could not drop in pgAdmin because I was unable to close all open connections in pgAdmin.
Close pgAdmin-4.
In Windows command line, assuming my server's name is postgres and my database is mydb:
C:\> psql -U postgres
I logged in with my server password.
I then closed all open connections to mydb:
postgres-# SELECT * FROM pg_stat_activity WHERE pg_stat_activity.datname='mydb';
postgres-# SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'mydb';
Finally, I successfully dropped mydb:
postgres-# DROP DATABASE mydb;
Now if I go back into pgAdmin-4 it is gone.
To drop the database:
\c postgres
Then
DROP DATABASE your_database works
It's simple, just connect to another database \c database2. Once connected execute the drop database command while connected to the other database.
Just Connect to a different database using \c db_name;
and then drop the required database using drop database db_name;
If you are using DBeaver make sure you are not connected to the database you are trying to drop. Go to edit connections and look at the database name.
Switch the connection to a different database and then drop the database you wish.
None of this worked for me since I tried to do it through pgAdmin which kept database connections open as soon as I delete them.
Solution:
C:\Program Files\PostgreSQL\11\scripts\runpsql.bat
after you supply correct information you will be able to get pg command prompt, here you can just type:
dbdrop yourdatabase
After that you might still see database in pgAdmin but now you can just simply delete it with right click and DELETE/DROP option.
you can force to drop database with: DROP DATABASE mydb WITH (FORCE)
I'm trying to rename a database in my Redshift cluster.
You cannot rename the database when you're connected to it so I've created a temporary database, reconnected with SQL Workbench to the temporary db and issued:
ALTER DATABASE olddb RENAME to newdb;
I get an error stating ERROR: database "olddb" is being accessed by other users [SQL State=55006]
I've checked who is connected and there appear to be some connections from user rdsdb to the database. I assume this is a service account that AWS Redshift use to perform maintenance tasks etc.
How can I rename the database when this superuser is connected?
Many thanks.
You cannot alter the name of (or delete!) the database that is created during the initial cluster creation. I don't believe this is mentioned in the docs but I've confirmed it with them.
We can change the database name which is already created.
Detailed steps on how to do
Connect to the old database and create a new database if you do not have another one already.
create database databasebasename
In this example, I will call the databasename as 'newdb'.
Connect to newdb using connecting string as, jdbc:redshift://.us-east-1.redshift.amazonaws.com:8192/newdb, with the same password and username of your superuser (or the other eligible users as mentioned above).
Now you can alter the database name. Substitute 'database_name_new' with the desired databasename.
alter database old-db-name rename to database_name_new;
If there are any active sessions, you'll have to kill them. To find the pid of active sessions:
select * from STV_SESSIONS where user_name='rdsdb';
Then to kill a session:
SELECT
pg_terminate_backend(<pid>)
FROM
pg_stat_activity
WHERE
-- don't kill my own connection!
procpid <> pg_backend_pid()
-- don't kill the connections to other databases
AND datname = '<old-db-name>';
Once complete, you can connect back to that new database using the new name in the connection string as
jdbc:redshift://<cluser-id>.us-east-1.redshift.amazonaws.com:8192/database_name_new
You can delete the temporary 'newdb'.
drop database databasebasename
That's possible now -- I just renamed the database that was created during the initial cluster creation.
We had a similar situation.
Step 1: Connect to the database which is not the one you are trying to rename. Check the same by executing SELECT CURRENT_DATABASE();.
Step 2: Execute the query below -
SELECT
ss.*, 'select pg_terminate_backend('||process||');'
FROM
stv_sessions ss
ORDER BY
db_name;
The output of the query will have a column at the end with the select statements. Execute those to kill the sessions.
Step 3(Optional): If you are not the owner of the database try to modify the ownership of the database -
ALTER DATABASE <database to be renamed>
OWNER TO <user which is going to do the rename>;
Step 4: Rename the database