Permission denied after pg_upgrade on RDS - postgresql

After trying to upgrade a shadow-copy of our PostgreSQL 9.6.6 RDS instance to 10.4, most operations on the database, including those done with a "root" user (the one created when setting up the database), result in an error like this:
SQL Error [42501]: ERROR: permission denied for schema public
Position: 15
Another example is a query like select * from example_table limit 100; which results in the error:
SQL Error [42P01]: ERROR: relation "example_table" does not exist
Position: 15
ERROR: relation "example_table" does not exist
Position: 15
ERROR: relation "example_table" does not exist
Position: 15
However, I am able to execute SELECT * FROM pg_catalog.pg_tables where schemaname = 'public'; which correctly lists all my tables
The upgrade logs don't seem to show anything unusual. I've been unable to find any RDS-specific instructions on upgrading from 9.x to 10.x so I assumed that the normal upgrade procedure in the interface (which I've used in the past and seems to be using a pg_upgrade operation) would "just work". Is there anything I'm missing?

Related

PostgreSQL copy issues

I am trying to copy my PostgreSQL query result set into an excel file since Tableau Public does not connect to PostgreSQL.
I am unsure how to get my result set into excel. I've been watching countless YouTube vids and read numerous stack overflow & postgresql threads to no avail. I am using postgresql 14 on pgadmin on a Mac. Appreciate any response!
The code below is what I tried and I get this error message:
copy (select * from emp) to '/Users/my_name/Desktop/sql_query.csv' with csv
ERROR: could not open file "/Users/my_name/Desktop/sql_query.csv" for writing: Permission denied
HINT: COPY TO instructs the PostgreSQL server process to write a file. You may want a client-side facility such as psql's \copy.
SQL state: 42501
I also tried \copy and got this error message:
ERROR: syntax error at or near "\"
LINE 1: \copy (select * from emp) to '/Users/my_name/Desktop/sq...
^
SQL state: 42601
Character: 1

PostGIS doesn't work after update in Manjaro

I recently ran a full update on my Manjaro-System, afterwards, when I tried to run a small script I use to start and automatically save my Postgres-DB I get the following error in the shell.
pg_dump: error: query failed: ERROR: could not load library
"/usr/lib/postgresql/postgis-3.so": /usr/lib/postgresql/postgis-3.so:
undefined symbol: list_make1_impl
pg_dump: error: query was:
SELECT
a.attnum,
a.attname,
a.atttypmod,
a.attstattarget,
a.attstorage,
t.typstorage,
a.attnotnull,
a.atthasdef,
a.attisdropped,
a.attlen,
a.attalign,
a.attislocal,
pg_catalog.format_type(t.oid, a.atttypmod) AS atttypname,
a.attgenerated,
CASE WHEN a.atthasmissing AND NOT a.attisdropped THEN a.attmissingval ELSE null END AS attmissingval,
a.attidentity,
pg_catalog.array_to_string(ARRAY(SELECT pg_catalog.quote_ident(option_name) || ' ' || pg_catalog.quote_literal(option_value) FROM pg_catalog.pg_options_to_table(attfdwoptions) ORDER BY option_name), E',
') AS attfdwoptions,
CASE WHEN a.attcollation <> t.typcollation THEN a.attcollation ELSE 0 END AS attcollation,
array_to_string(a.attoptions, ', ') AS attoptions
FROM pg_catalog.pg_attribute a LEFT JOIN pg_catalog.pg_type t ON a.atttypid = t.oid
WHERE a.attrelid = '18597'::pg_catalog.oid AND a.attnum > 0::pg_catalog.int2
ORDER BY a.attnum
Also, when I start the database in pgAdmin I can open all the tables except the one which holds the geography-column, which needs PostGIS. It shows me the following error instead:
ERROR: could not load library /usr/lib/postgresql/postgis-3.so: /usr/lib/postgresql/postgis-3.so: undefined symbol: list_make1_impl SQL state: 58P01
Apparently something in the proj-package is messed up. According to this thread, it could have something to do with this package being installed several times. However, I reinstalled proj manually, from the Official Repo as well as from the AUR each time with a different version and cleaned the old version every time. The error is still there.
Currently the version setup is:
QGIS: Version 3.16.5
Postgres: Version 12.6-1
PostGIS: Version 3.0.3-1
proj: Version 6.3.2-1
Manjaro: KDE-Plasma 5.21.3
Kernel: 4.19.183-1-Manjaro
Does anyone have a solution for this?
Thanks to the local Linux User Group I found a solution to the problem. It turned out, that PostGIS was updated in the background and the new version did not correspond with PostgreSQL 12.6 any more. Since PostGIS was already installed, it did not show me this but the error message above instead.
To check if PostGIS is still compatible with PostgreSQL, I create a new database and then tried to add the PostGIS extension. I got the following message, that cleared things up:
test=# CREATE EXTENSION postgis;
ERROR: could not open extension control file "/usr/share/postgresql/extensionpost.control": No such file or directory
test=# CREATE EXTENSION postgis;
ERROR: PostGIS built for PostgreSQL 13.0 cannot be loaded in PostgreSQL 12.6
So I updated PostgreSQL, set up a new database cluster and used pg_restore on the last .sql from my automatic pg_dump to recreate the database. It now works as before again.

ERROR: syntax error at or near "ALL" postgres GRANT psql 8.4.15

I have a postgresql version 8.4.15 database and when I want to give a user permissions on tables, I get a syntax error that in postgres version 11.5 it doesn't.
ERROR: syntax error at or near "ALL"
LINE 1: GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO consulta;
ERROR: syntax error at or near "ALL"
LINE 1: GRANT SELECT ON ALL TABLES IN SCHEMA public TO consulta;

postgres liquibase limit diff to one schema

Goal:
I created a special login (named liquibase) which has only acces to one schema CustomerXX (the schema which I would like to compare and only this!!)
Problem:
Even with this login limited the liquibase diff operations try to read other schema (as exemple in my error obsolete_objects)
Remark:
I am studing the CustomerXX. I have another schema in the database named obsolete_objects but i am only focus on customerxx
login liquibase used ==>
GRANT all ON schema customerxx to liquibase;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA customerxx to liquibase;
no other right
My command liquibase:
liquibase.bat
--classpath="E:\Program Files\Talend-Studio\plugins\org.talend.libraries.jdbc.postgresql_5.5.1.r118616\lib\postgresql-9.2-1003.jdbc3.jar"
--driver=org.postgresql.Driver --url=jdbc:postgresql://xxxxxxxxx
--username=USERNAME
--password=PASSWORD
--defaultSchemaName=customerxx
Diff
--referenceUrl=jdbc:postgresql://yyyyyyyyyy
--referenceUsername=liquibase
--referencePassword=liquibase
--referenceDefaultSchemaName=customerxx
My error
Diff Results:
Unexpected error running Liquibase: liquibase.exception.DatabaseException:
org.postgresql.util.PSQLException: ERROR: permission denied for schema obsolete_objects PositionĂ¡: 27
Thanks in advance!

Many syntax and permissions errors on postgres sql dump import

I am trying to import a .sql database dump into my postgres 9.6.1. I've tried in command line as well as the Postico GUI but get a ton of errors (like thousands of lines of errors) on import.
The SQL dump is from a coworker running postgres 9.4.5 and the SQL looks valid.
My Postgres Version:
PostgreSQL 9.6.1 on x86_64-apple-darwin, compiled by
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.
build 5658) (LLVM build 2336.11.00), 64-bit
I've tried the following imports:
psql -U postgres dbname < ~/Desktop/dbname_local_db_20161122.sql
Then logging in and trying it:
psql -U postgres dbname
dbname=# \i ~/Desktop/dbname_local_db_20161122.sql
Errors: (there are way more than this)
Password for user postgres:
SET
SET
SET
SET
SET
SET
CREATE EXTENSION
COMMENT
ERROR: schema "public" does not exist
ERROR: extension "citext" does not exist
ERROR: schema "public" does not exist
ERROR: extension "pg_trgm" does not exist
SET
ERROR: function "add_session_metric" already exists with same argument types
ERROR: role "myrole" does not exist
ERROR: function "session_metrics_partition_creation" already exists with same argument types
ERROR: role "myrole" does not exist
ERROR: function "session_metrics_partition_function" already exists with same argument types
ERROR: role "myrole" does not exist
SET
SET
ERROR: permission denied to create "pg_catalog.messages"
DETAIL: System catalog modifications are currently disallowed.
ERROR: relation "messages" does not exist
ERROR: permission denied to create "pg_catalog.Message_id_seq"
DETAIL: System catalog modifications are currently disallowed.
ERROR: relation "Message_id_seq" does not exist
ERROR: relation "Message_id_seq" does not exist
ERROR: permission denied to create "pg_catalog.sessions_users"
invalid command \N
invalid command \N
invalid command \N
invalid command \N
invalid command \N
invalid command \.
ERROR: syntax error at or near "2"
LINE 1: 2 hello 3 1 2015-11-12 09:25:14.646-07 2015-11-12 09:25:14.64...
ERROR: syntax error at or near "1"
LINE 1: 1
^
ERROR: relation "external_session_info_sessions" does not exist
invalid command \.
ERROR: syntax error at or near "2528"
LINE 1: 2528 1
^
invalid command \.
ERROR: relation "feedback_id_seq" does not exist
LINE 1: SELECT pg_catalog.setval('feedback_id_seq', 1, false);
Like I said, the SQL file looks valid. I've checked for compatibility issues from 9.4.5 to 9.6.1 but don't see any.
I do see PERMISSION DENIED but I am running the command as user postgres which has super user permissions:
First, the recommended way is to use pg_dump from the higher (target) database version to create the dump, because that version of pg_dump knows about incompatible changes that happened since and can create a dump that will restore correctly.
Some of the errors are normal if you restore a dump into a database that already has objects with the same names in it; often that is a sign that the dump should actually have been created with pg_dump -C to include a CREATE DATABASE statement.
However, your SQL script seems seriously messed up, and I doubt that it is an unmodified dump of a 9.4.5 database.
pg_dump will never dump any objects in pg_catalog. This schema can only contain system objects which are not included in a dump (they are created by CREATE DATABASE), and as you have seen, not even a superuser may create an object in that schema (unless allow_system_table_mods is on, which it really shouldn't be).