I have a table in Heroku Postgres (Hobby tier) with a "jobs" table. I am using PGAdmin to view and work with the database.
If I view the dependents tab for the "jobs" table, I can see that an index exists "public.ix_public_jobs_next_run_time".
From the query tool, I run the query "DROP INDEX public.ix_public_jobs_next_run_time;" and get the following error:
ERROR: index "ix_public_jobs_next_run_time" does not exist
SQL state: 42704
Why can't I drop this index?
Background: I am using SQLAlchemy ORM to db upgrade my postgres database to modify some tables. The db upgrade command fails when it tries to drop the index. I used the steps above to recreate this error.
Perhaps you set a search_path that does not include public. Then you have to name the schema explicitly:
DROP INDEX public.ix_public_jobs_next_run_time;
Another option is of course that you connected to the wrong database when you tried to drop the index.
Related
I am new to Postgresql and so far I have not found a way to drop a table from specific database. To give some context:
We are doing a synchronization from Oracle to PostgreSQL of 5 tables. In postgres I have a database SoloCopy and the schema is the default public. In the Postgresql instance we have also 2 more databases SoloSynch and postgres (the default one).
What I want to do is to select SoloCopy database and:
DROP TABLE public.table1;
When I do the above DROP statement table1 is deleted only from the database that was selected when opening SQL Query. But I want to specify the database before that and to be irrelevant from where the SQL Query was open. How can I do that?
I found an answer on my own. Setup can be found here:
Psql in Task Scheduler does not run a file script
Basically I needed to use PSQL and with the connection string there I connect to a specific DB, which I can drop the tables from. The details for PGPASSWORD and the .bat file I ended up creating are in the link above. Had to start everything from CMD and switch to psql from there.
I'm new to Postgres and Heroku. I've inherited a project with a Postgres DB hosted on Heroku and I'd like to export it from there for local use inside Docker. I've got as far as exporting and then restoring (via pg_restore) the DB inside my container, but when it builds my DB I get loads of warnings like:
pg_restore: from TOC entry 285; 1259 16897 TABLE foo u2ae1fgct609sl
pg_restore: error: could not execute query: ERROR: role "u2ae1fgct609sl" does not exist
Command was: ALTER TABLE public.foo OWNER TO u2ae1fgct609sl;
Presumablty this is because I've exported/restored the DB but not the corresponding users. Heroku doesn't seem to mention this part in its docs on exporting/restoring/importing Postgres DBs.
What can I do about this? Can I somehow tell it to set as the owner the DB user that Docker created when spinning up the container, or am I on the wrong lines?
I have created a database foo which I am using as a template database to create other databases from.
I am running all PostgreSQL in a Docker container (not sure if that is relevant to the problem at hand).
Here is the (truncated) SQL
CREATE DATABASE foo WITH ENCODING 'UTF8' template0;
\i db_schema_foo.sql
-- Create extensions
-- Initialise db with data etc ...
CREATE DATABASE foobar TEMPLATE foo;
(Truncated) console output:
CREATE DATABASE
You are now connected to database "foo" as user "postgres".
CREATE TABLE
CREATE INDEX
CREATE TABLE
CREATE INDEX
CREATE TABLE
...
CREATE INDEX
CREATE TABLE
CREATE INDEX
CREATE TABLE
CREATE TABLE
CREATE TABLE
CREATE TABLE
CREATE TABLE
CREATE TABLE
CREATE INDEX
CREATE TABLE
CREATE INDEX
CREATE TABLE
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE DATABASE
FATAL: database "foobar" does not exist
psql:/docker-entrypoint-initdb.d/create_databases.sql:82: \connect: FATAL: database "foobar" does not exist
From the console, I'm assuming that both foo and foobar are created - so why can't I connect to database foobar?
Use the psql command \l to see which databases exist.
I would expect database foobar to not exist.
That would mean that the CREATE DATABASE statement has failed.
Can you get the error message for that?
My suspicion is that creating the database failed because you were still connected to the template database foo. You can only use a database with no active connections as template.
CREATE DATABASE in output means either that databse was successfully created, if there would be error and no warning, like here:
t=# set client_min_messages TO fatal;
SET
t=# create database t;
t=# set client_min_messages TO warning;
SET
t=# create database t;
ERROR: database "t" already exists
there would not be such output - CREATE DATABASE
so next line FATAL: database "foobar" does not exist (together with knowledge database was created) leads to idea that OP is connecting to different cluser, or different database
In private chat we found that database created was "Foobar" and database attempting to connect was Foobar and thus "foobar", which does not exist indeed, as "Foobar" does
I'm trying to move a database in Postgres 8.2 to a new tablespace, but when running ALTER DATABASE data_base_name SET TABLESPACE TO tbspc_name
the following error appears ERROR: unrecognized configuration parameter "tablespace".
It seems that in Postgres 8.2 you have two options:
move tables one by one, see ALTER TABLE ...;
backup the database, create a new one with a tablespace defined, and restore the backup in the new database, see CRETE DATABASE ....
I am trying to import a sql dump to postgresql db as -
sudo su postgres -c psql dbname < mydb_dump.sql
This gives errors as -
SET
SET
SET
SET
SET
SET
ERROR: function "array_accum" already exists with same argument types
ALTER AGGREGATE
ERROR: function "c" already exists with same argument types
ALTER AGGREGATE
ERROR: duplicate key value violates unique constraint "pg_ts_config_cfgname_index"
ERROR: duplicate key value violates unique constraint "pg_ts_config_map_index"
and so on this. What might be wrong with that? Tried googling for it, but couldn't find any pointers over it.
Postgresql version is 8.4.1
Thanks !!
you should to remove shared functions and objects from database, before you do dump or before you load dump. You have these functions and objects registered in template1, and when you create new database, then these objects are there - and you can see errors when dump try to create it again.
This issue is well solved in PostgreSQL 9.1. For older versions try to use option --clean for pg_dump
Pavel