I am a complete beginner with postgresql. I created a test database called iswdp and now I want to delete it. When I do:
dropdb iswdp
the command returns no output and when I \list the table iswdp is still there.
dropdb iswdp;
returns:
ERROR: syntax error at or near "dropdb"
LINE 1: dropdb iswdp
I used:
SELECT pg_terminate_backend(pg_stat_activity.pid)
FROM pg_stat_activity
WHERE datname = current_database()
AND pid <> pg_backend_pid();
which I found from another stackoverflow post to disconnect from all databases then attempted dropdb iswdp again with the same result.
I'm stuck, can someone help me? I'm doing this on linux mint from the bash terminal.
The command dropdb is a command issued from a shell prompt. From a sql prompt (like psql), you would want to issue a DROP DATABASE command.
I recommend opening psql and issuing DROP DATABASE iswdp;. That should work.
You may get an error that looks like ERROR: cannot drop the currently open database, which will happen if you connect to iswdp and try to drop it. If that happens, try instead to connect to the postgres database, and issue the same DROP DATABASE command. It should work.
dropdb is a commando from shell not from psql program, from psql the commnado is drop database iswp;
Related
I'm trying to execute two sql commands (create a new schema and table), in a way that would enable a rollback of both commands if the execution fails. The database I'm connecting to is AWS Redshift.
create schema if not exists test_schema;
create table test_schema.test_table as select 1;
Initially I tried to execute these commands programatically with python, using both psycopg2 and pyodbc, and got the following error:
ERROR: schema "test_schema" does not exist
I realised that it fails because the first command isn't being comitted, so to fix that , I tried setting the autocommit mode on, and wrapping the statements with "begin/end" block, which didn't help.
When I used psql CLI and ran the following, everything worked as intended (there was no "schema does not exist" error, and after the rollback, both schema and table were gone):
dev=# begin;
BEGIN
dev=# create schema test_schema;
CREATE SCHEMA
dev=# create table test_schema.test_table as select 1;
SELECT
dev=# rollback;
ROLLBACK
I tried to get the same results by running the following in the command line:
psql -c "begin; create schema test_schema; create table test_schema.test_table as select 1;"
This results in the same error:
ERROR: schema "test_schema" does not exist
However, when I put the above code in a file and ran the same command, this time using -f, it worked:
psql -f create_schema_and_table.sql
My questions are:
What is the difference between executing queries with "psql -c" and "psql -f"?
How can the same result be achieved programatically, with python?
Thanks a lot!
I don't know what you are doing wrong, your "psql -c" command works perfectly fine:
ads#diamond:~$ psql -c "begin; create schema test_schema; create table test_schema.test_table as select 1;" postgres
SELECT 1
psql will send the entire string to the server, and execute it in one single transaction. Your problem is that you start a transaction using "begin", but never commit it. Therefore at the end of the psql run, all your changes are rolled back. The next psql command will not find the schema, nor the table. But as long as everything stays in a single psql call, subsequent queries in the same command can see newly created objects.
Your query string should instead look like:
begin; create schema test_schema; create table test_schema.test_table as select 1; commit;
Or, more easy:
create schema test_schema; create table test_schema.test_table as select 1;
Both will work.
I am aware of only truncate command in sqlplus,
connect myuser/mypassword#myserver
truncate table mytable;
EXIT;
/
Wondering if there is a delete command, I read about DEL but not sure how to use it appropriately, please advice if there is something to use like the below in sqlplus if any,
delete from mytable where emp_id in (1,5);
Answer to your question is yes.
In fact, what you have written is a perfectly valid delete command.
See http://www.techonthenet.com/oracle/delete.php for a simple tutorial and guide. Not just Oracle, but all SQL databases support it. It is part of the SQL language itself.
Running following statement in DB2 CLP (Command Window)
db2 "truncate table MYSCHEMA.TABLEA immediate"
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0969N There is no message text corresponding to SQL error "-20356" in the
message file on this workstation. The error was returned from module
"SQLNQBE2" with original tokens "MYSCHEMA.TABLEA".
Can some please tell me what I'm doing wrong or what I'm missing? I'm trying to simply truncate from a single table and I'm getting the following error message. Not sure what I'm doing wrong. I've tried it with/without quotes, with/without schema, with/without immediate. I've also tried in Command Editor (remove db2 and quotes) and still not working. I'm using:
DB2/AIX64 9.7.9
Also, I have delete privilege as I am able to delete records but I want to truncate.
Thanks in advance!
The version of the DB2 client you're using doesn't seem to match that of the server, this is why you cannot see the actual error message for SQLCODE -20356. If you could, you'd see this:
The table MYSCHEMA.TABLEA cannot be truncated because DELETE triggers
exist for the table, or the table is the parent in a referential
constraint.
Further explanation and suggested actions can be found, as usual, in the fine manual.
ALTER TABLE MYSCHEMA.TABLEA ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE
or
import from /dev/null of del replace into MYSCHEMA.TABLEA
I had this problem recently too. In my case I had to do a COMMIT WORK right before TRUNCATE. This solved my problem. Please try and tell us if this helped.
I am trying to reset temporary tables via a simple commandline script and am using the following command:
#echo DELETE FROM A ; | sqlplus schema/pass#DSN
This works for table A.
For a similar table B, the statement is not executed. The commandline logs into the database and displays the SQL> shell. It does not react to keystrokes and does nothing. I have to exit the commandline interface.
I tried different ordering of the commands in the batch file and executed the statement from commandline directly. Same error.
(Question answered in a comment. See Question with no answers, but issue solved in the comments (or extended in chat) )
#Alex Poole wrote:
Do you have an uncommitted delete or update against that table in any other open sessions? In a Toad or SQL Developer window, for example? If you've tested the delete somewhere, roll back in that session and see if the batch version magically finishes.
The OP wrote:
Worked. I should have tried that before posting. Now I feel retarded.
SOLUTION: Uncommitted transactions in open session on table caused the error. Once transactions had been committed, the script worked fine.
I tried connecting to the database server using the command:
psql -h host_ip -d db_name -U user_name --password
It displays the following line and refuses to connect.
psql: FATAL: too many connections for role "user_name".
How to close the active connections?
I do not have admin rights for the database. I am just an ordinary user.
From inside any DB of the cluster:
Catch 22: you need to be connected to a database first. Maybe you can connect as another user? (By default, some connections are reserved for superusers with the superuser_reserved_connections setting.)
To get detailed information for each connection by this user:
SELECT *
FROM pg_stat_activity
WHERE usename = 'user_name';
As the same user or as superuser you can cancel all (other) connections of a user:
SELECT pg_cancel_backend(pid) -- (SIGINT)
-- pg_terminate_backend(pid) -- the less patient alternative (SIGTERM)
FROM pg_stat_activity
WHERE usename = 'user_name'
AND pid <> pg_backend_pid();
Better be sure it's ok to do so. You don't want to terminate important queries (or connections) that way.
pg_cancel_backend() and pg_terminate_backend() in the manual.
From a Linux shell
Did you start those other connections yourself? Maybe a hanging script of yours? You should be able to kill those (if you are sure it's ok to do so).
You can investigate with ps which processes might be at fault:
ps -aux
ps -aux | grep psql
If you identify a process to kill (better be sure, you do not want to kill the server):
kill 123457689 # pid of process here.
Or with SIGKILL instead of SIGTERM:
kill -9 123457689
I'm pretty new to pgAdmin, but so far I have not utilized the command line. I had the same issue and I found the easiest way to resolve the issue in my case was to simply delete the processes listed in "Database Activity" in the Dashboard.
(just click the X on the left side of the PID)
It's a bit tedious since you must delete each process individually, but doing so should free up your available connections.
Hope this is useful.
You need to connect on your postgresql db and run command:
ALTER ROLE your_username CONNECTION LIMIT -1;
Check pool_size this is probably too much or to small set value on local psql settings. You should at first check with pool_size = 10 (like default). This should fix errors of too_many_connections.
Please check how many connections are allowed on that user and you can just kill other connections for that user and log in again. But it's better to just increase the connection limit for that user.
This issue mostly arises on PgAdmin. It seems like after all these years still this issue persists.
This will drop existing connections except for yours:
Query pg_stat_activity and get the pid values you want to kill, then issue SELECT pg_terminate_backend(pid int) to them.
PostgreSQL 9.2 and above:
SELECT pg_terminate_backend(pg_stat_activity.pid)
FROM pg_stat_activity
WHERE pg_stat_activity.datname = 'TARGET_DB' -- ← change this to your DB
AND pid <> pg_backend_pid();
PostgreSQL 9.1 and below:
SELECT pg_terminate_backend(pg_stat_activity.procpid)
FROM pg_stat_activity
WHERE pg_stat_activity.datname = 'TARGET_DB' -- ← change this to your DB
AND procpid <> pg_backend_pid();
from https://stackoverflow.com/a/5408501/13813241 (duplicate)
I was getting this for a specific incident.
Django Development. I had a shell open to query django models. I also have the dev server running. I was using elephantsql for testing/prototyping. So it threw error. Once I exited out of django manage.py shell, it started working.