I'm trying to run a postgresql Database on Ubuntu 16.04 LTS.
First I installed postgres using sudo apt-get install postgresql which installed version 9.5.1. I then created another user and a new database. I've granted all privileges for the new database to new new user and set the owner to the new user also.
I connected to the new database and filled it by restoring an plain backup (dump) I've created from another database (which has postgresql version 9.2) by using \i /path/to/dump.sql. I got no errors, and when I then typen \dt I got the list with the tables.
The problem is: When I now disconnect (\q) and re-connect (same as I connected before, sudo psql -U "username" dbname) and type \dt again, it says "No relations found". When I try to fill it again, I get a bunch of errors like "Relation relationname already exists".
Another problem/symptom appears when I try to use pgAdmin (installed via sudo apt-get install pgadmin3). When trying to connect using localhost, I can't connect using the newly created user (which which I can connect from the terminal). But I can connect using postgres with the password I set via Terminal. I do not see any DB I manually create from command line from pgAdmin tho.
So yeah, my guess is that at least one problem may be version incompatibility between 9.2 and 9.5. Is there any way to test/fix this? But I also think there should be other problems.
What you describe may happen if the SQL dump contains a SET search_path TO...command that sets it to a different value than what your user has by default.
So not only it will create its tables and other objects in that schema, but it will leave that search_path for the rest of the session, so when you do \dt in that same session, it does see and list the newly created tables.
But when you quit and reenter psql, this search_path is not longer in effect, you're back to the default search_path of your user, which supposedly doesn't reach the schema, so \dt no longer "sees" any table.
You can use show search_path to check this setting in a psql session, and grep "SET search_path" in the SQL file to check what it's being set to.
Per comment, it appears to be the case: the dump creates the tables into a schema that is outside of the user's default search path.
A possible solution for that user to work seamlessly would be to update its search path so that it always reaches this schema first. This can be done with:
ALTER USER username SET search_path TO schema1,"$user",public;
where schema1 is what the SQL dump refers to and where it created the tables.