I exported a database using dokku postgres:export dbname and imported it to another instance using dokku postgres:import dbname. The application running on the new instance does not connect correctly to the new imported database. It is connecting to the database itself, but the data is not there. I entered connected to both instances. Running \l both were identical. However when I run \dt is where the difference is.
Actual Results
// On the new instance
=# \dt
List of relations
Schema | Name | Type | Owner
--------+------------------------+-------+----------
public | document | table | postgres
...
// On the original instance
=# \dt
List of relations
Schema | Name | Type | Owner
--------+------------------------+-------+----------
dbname | document | table | postgres
...
The data was moved over, but is is the public schema (I think). Running select queries gives me different results as well.
// Original machine
SELECT * FROM document;
// Returns the data
SELECT * FROM dbname.document;
// Also returns the data
// New machine
SELECT * FROM document;
// Empty result
SELECT * FROM dbname.document;
// Returns the data
Expected Results
I guess I would expect that exporting from one db and importing to another with the same name would produce nearly identical instances. Any help here would be great. Everything else is working great in the app, it connects to the db, but returns no data.
In case anyone has this problem I got it working by connecting to the postgres instance by running dokku postgres:connect dbname and changing the search_path from "$user", public to dbname, public. It works for now. However I don't feel like this is the best solution.
Related
I have Postgres 9.6 installed on mac os. When I enter the command:
$ psql (it takes me to below prompt)
bar=#
bar=# \conninfo
You are connected to database "bar" as user "bar" via socket in "/tmp" at port "5432".
How do I get out of database bar and be at the top level so that when I enter command:
CREATE DATABASE postgis_in_action;
CREATE SCHEMA ch07;
CREATE TABLE ch07.bag_o_rasters(rid serial primary key, rast_name text, rast raster);
database postgis_in_action will be created and within this database ch07 schema will be created and not nested inside database "bar" and the table will be created within ch07 schema under postgis_in_action database?
After creating the new database you need to switch to it. Otherwise the create schema will be run in the database to which you initially connected. In psql you can do that using \connect
bar=# CREATE DATABASE postgis_in_action;
bar=# \connect postgis_in_action
You are now connected to database "postgis_in_action" as user "postgres".
CREATE SCHEMA ch07;
CREATE TABLE ch07.bag_o_rasters(rid serial primary key, rast_name text, rast raster);
I would strongly recommend you create a regular user to do your work. Do not do everything as the superuser. E.g.:
bar=# create user ace password '*******';
bar=# create CREATE DATABASE postgis_in_action owner ace;
\connect postgis_in_action ace
Password for user ace:
You are now connected to database "postgis_in_action" as user "ace".
postgis_in_action=>
Maybe you have an experience with other databases, but this is the Postgres. Schemas are nested in databases, and you cannot to connect to schema (in Postgres). If you want create the database, then you use CREATE DATABASE ch07 instead CREATE SCHEMA ch06.
Instance (Postgres Cluster)
|
v
-------------------- ...
| |
v v
Database1 Database2
|
----------------------- ...
| | |
v v v
public schema1 schema2
|
----------------------- ...
| | |
v v v
table1 table2 table3
In this case the Postgres is similar to MS SQL, and very different to Oracle. Schema in Postgres and Oracle are different things.
When you connect to Postgres, then you have to specify target database. You cannot to connect just to server, or you cannot to connect to schema. Schemas (in Postgres) are like directories. You can specify an order of searching of schemas. You can set SEARCH_PATH per connect, per user or in an session (it is analogy of PATH in MS Win or UNIX).
I am working on this flask based web app. While things are working fine in the app, I wanted to verify the same in my postgres database.
While I can access user data in my app, I am not able to see the same when I try to access while SQL command on the terminal. This problem is specific to the 'user' table, while other tables could be accessed normally on terminal too.
This is the result of my user query:
classroom=# SELECT * FROM user;
user
-------
fatih
(1 row)
and this is some other table in the same database:
classroom=# SELECT * FROM course;
id | title | code
----+-----------------------------+----------
3 | Algorithms | COC2030
4 | Web development using Flask | FLASK001
(2 rows)
I am expecting the same type of result as in the course table, as in the user table.
Assuming there are more columns or rows in the user table that you'd like to see, you could try:
Log in using the same user as the flask app.
Log in as user postgres and check if that changes things (sudo -u postgres psql classroom, or psql classroom postgres.)
Use the \dp command to see if there are column privileges.
Use the \dn+ command to see if there are row security policies.
In order to change the collation of PostgreSQL's database template, I dropped template1 and recreated it with the 'correct' collation. I therefore got my inspiration from this question.
All fine now, but now that newly database template template1 is listed in the available databases in the tree view.
I compared database pg_database for two servers (one listing the database template1, one not), but the values of the parameters for database template1 are the same.
I would like to hide this database from in the tree view.
Anyone who can figure this out?
EDIT: this one did not bring me any further
(PostgreSQL 9.6, pgAdmin 1.22)
PgAdmin uses the following condition to show the database in the tree or not:
/* Condition used to show database */
if (settings->GetShowSystemObjects() || !database->GetSystemObject())
(...)
/* Function called above */
bool pgDatabase::GetSystemObject() const
{
if (server)
{
if (this->GetName() == wxT("template0")) return true;
return (this->GetOid() <= server->GetLastSystemOID());
}
else
{
return false;
}
}
Unless you've marked "Show System Objects in the treeview" option, I guess that your template1's oid is greater than LastSystemOID (pg_database.datlastsysoid). In this case you have three options:
Rebuild your cluster with right collation;
Accept that;
or, assuming you weren't in production, play with
pg_database.datlastsysoid and wait for side effects.
PgAdmin had an issue where template1 was shown even if the option was turned off to show system objects. This happened when you migrated your database before via pg_upgrade.
The image below shows the template database in the current pgAdmin version with the Show system object option enabled:
The issue was in the condition shown by Michel Milezzi. It is not correct to determine that a database is a template by oid <= lastSystemOid. Because when you use pg_upgrade, the oid of the template1 database is changed and the new value is higher than the lastSystemOid (i don't know if this is also a bug).
oid datname datlastsysoid datacl
13394 template0 13394 {=c/postgres,postgres=CTc/postgres}
1 template1 13394 {=c/postgres,postgres=CTc/postgres}
after using pg_upgrade:
13756 template0 13756 {=c/postgres,postgres=CTc/postgres}
16446 template1 13756 {postgres=CTc/postgres,=c/postgres}
^
As a Rails novice, I'm following instructions in railscast #342 to set up a postgres database connection on my Mac.
I created a new rails project with
$ rails new blog -d postgresql
I edited the database yaml file to set the username and password.
I used psql to add the new user and password, and gave it permission to create tables: alter user blog create db
I created the db via
rake db:create:all
It succeeded and inside psql, doing \l to list schemas, I see all three schemas blog_test, blog_development and blog_production
I then do
$ rails g scaffold article name content:text
all looks good
I then do
$ rake db:migrate
I get messages showing success:
$ rake db:migrate
== 20150701220010 CreateArticles: migrating ===================================
-- create_table(:articles)
-> 0.0128s
== 20150701220010 CreateArticles: migrated (0.0129s) ==========================
I set my search path to look at the schema:
set search_path to lcuff,public,blog_development;
show search_path:
search_path
---------------------------------
lcuff, public, blog_development
But trying to find the table,
# \d
No relations found.
I've done the db:migrate VERSION=0 and it successfully reports that it drops the table, and then I create it again with db:migrate and it reports success.
If the first part hadn't worked, where it actually created the schema, I'd think I'm pointed to the wrong database somehow.
Ideas?
You should first connect to the database before fetching the tables.
\connect blog_development
And then try giving \d to list all tables.
You can also try with \dt.
Example(Tested in my Project):
\connect my_db
You are now connected to database "my_db" as user "postgres".
my_db=# \d
List of relations
Schema | Name | Type | Owner
--------+-------------------------------+-------+----------
public | access_managements | table | postgres
public | amenities | table | postgres
public | city_coordinates | table | postgres
public | coapplicants | table | postgres
Source
$ psql postgres
postgres=# \dn
List of schemas
Name | Owner
--------------------+----------
information_schema | postgres
pg_catalog | postgres
pg_toast | postgres
pg_toast_temp_1 | postgres
public | student
(5 rows)
When I log in to psql with user postgres, it shows that schema public is owned by user student. However, when I log in to psql with user student:
$ psql student
student=> \dn
List of schemas
Name | Owner
--------------------+----------
information_schema | postgres
pg_catalog | postgres
pg_toast | postgres
pg_toast_temp_1 | postgres
public | postgres
(5 rows)
It shows that schema public is owned by user postgres.
How can I get the ownership of schema public transferred to user student if the user with privileges to do so thinks that it's already done?
This is a misunderstanding. You are logging into two different databases.
When running
$ psql postgres
postgres is the name of the database. With default configuration the name of the database user is derived from the name of the system user using ident authentication automatically. The only parameter is assumed to be the database name. You do not want to change anything in the database postgres, it's a system database for maintenance tasks.
The other database is named student. Each database has a schema public with its respective owner.
Read the manual for psql or try a lowly man psql.
To transfer ownership of the schema public in the database student, log in as superuser:
psql -U postgres student
Or as operating system user postgres, just:
psql student
And run:
ALTER SCHEMA public OWNER TO student;
Details in the manual once more.