I'm using postgres 9.5.9. I have setup a FDW to a remote host. This all works ok. But when a new table is added to the remote host schema, the FDW does not see it. Usually I can do this...
IMPORT FOREIGN SCHEMA public LIMIT TO(new_table_name) FROM SERVER production INTO public;
But for some reason this isnt importing it this time.
> IMPORT FOREIGN SCHEMA public LIMIT TO(new_table_name) FROM SERVER production INTO public;
IMPORT FOREIGN SCHEMA
>
But then it doesnt see it
> \d new_table_name
Did not find any relation named "new_table_name".
How can I find what the cause of this is? I dont see anything in the logs about it.
EDIT
This ended up being a connection issue.
Related
I have existing schema for prisma.
I copied the table from another schema to be included in the Prisma schema.
But when I run prisma db pull new table doesn't appear in Prisma schema.
Why?
If you use supabase and running this command and it returns something like this 'The following models were commented out because we couldn't retrieve columns for them. Please check your privileges.' or something similar regarding privileges, the solution is to go to your SQL editor from supabase and put this command and execute it
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO postgres;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO postgres;
You're misinterpreting the function of the prisma db pull command.
From the docs
The db pull command connects to your database and adds Prisma models to your Prisma schema that reflect the current database schema.
Basically, it will make your Prisma schema match the existing database schema. What you want is the opposite here: Update the database schema to match the current Prisma schema.
You can do this in two ways:
If you want to update the database and keep the changes in your migration history, use the prisma migrate dev command. More Info
If you just want to update the database without creating a migration, use the prisma db push command. More info
More information is available in the docs explaining how you should choose between 1 and 2.
I had a similar issue once and a quick check confirmed for me that it was the lack of security permissions granted for prisma on new table in the database itself.
Try this:
Note the name of the database user that Prisma connects to the database with. You'll likely find this via your schema.prisma file, or perhaps via a DATABASE_URL config setting in the related .env file if you're using that with prisma.
Go into the database itself and ensure that database user which Prisma connects with has been granted sufficient security privileges to that new table. (note: what 'sufficient' is I cannot say since it depends on your own needs. At a guess, I'd say at least 'select' permission would be needed.)
Once you've ensure that user has sufficient privileges, try running a prisma db pull command once again.
For reference, another thing you could do is:
cross-check against one of the other tables that is already in your database that works correctly with prisma.
compare the security privileges of that old table with the security privileges of the new table and see if there are any differences.
I'm really stuck with the following problem.
At GCloud SQL I have a running postgres' instance.
That instance contains two databases. From one database (source_db) I want to access to another database's (another_db) table (foreign_table) using postgres_fdw extension. The recipe I'm employing currently is this:
1)
CREATE EXTENSION postgres_fdw;
CREATE SERVER foreign_db
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (dbname 'another_db', port '5432', host '<A_PRIVATE_IP>');
CREATE USER MAPPING for guest
SERVER foreign_db
OPTIONS (user 'guest', password 's3cr3t');
CREATE FOREIGN TABLE foreign_table
(
// columns descripions
)
SERVER foreign_db OPTIONS (table_name 'foreign_table');
-- Alternatively I also tried with
CREATE SCHEMA external;
IMPORT FOREIGN SCHEMA public from SERVER foreign_db into external;
GRANT SELECT ON TABLE foreign_table TO guest;
The above commands runs without error, but when I tried to actually access the table I got this:
If using "external" schema
source_db=> select 1 from external.foreign_table limit 1;
ERROR: permission denied for relation foreign_table
CONTEXT: Remote SQL command: SELECT NULL FROM public.foreign_table (*)
If not using "external" schema
source_db=> select 1 from foreign_table limit 1;
ERROR: permission denied for relation foreign_table
CONTEXT: Remote SQL command: SELECT NULL FROM public.foreign_table
The only thing that smells a little is that the error message (at *) displays "public.foreign_table" instead of "external.foreign_table" even when I'm using external schema... but i don't know is that actually means something :S
As far I researched there is no way to login into the posgres instance as a superuser as that is not allowed by the Gcloud's SQL services neither a way to edit the pg_hba.conf file in order to adjust client's authentication affairs.
I searched in a lot of places but without finding what i can do to sort this out. Among the sites and pages i looked are the below list
The official documentation
A personal blog's post
This other SO post having a related issue
This post and this other post regarding permissions and authorizations.
A Nice tutorial about authentication and authorization
P.S.
I was able to make this on a postgres' instance that i ran locally.
User guest on the remote server doesn't have permissions to SELECT from the table. Since the query on the remote server is executed as user guest, you get an error.
GRANT the SELECT privilege on the table on the remote server to the user.
hoping for some help as I am very new to postgresql admin!
I have 2 servers added to pgadmin, server 1 is a hosted db on Heroku the other is local to the server
I want to add the Heroku db as foreign tables to the local db
can I link these 2 servers? as so far I have failed
I have the fdw extension setup locally, and I am able to use it across three local dbs ok, do I need the extension also setup on the Heroku db?
I have setup the fdw server as
host localhost --- should this be the Heroku host path? or is this ok since I have added - --server local? I get fsrvoption error if I add actual host path
dbname dbname
port 5432
and then setup user
user username
password password
any help appreciated!
mal
You don't have to set up anything on the remote server to access it via foreign data wrapper; the foreign data wrapper will access the remote database as a regular database client.
Once you hace set up postgres_fdw correctly, you can use it to access tables on the remote server just as if they were local tables. A foreign table is a bit like a view in some respects.
Maybe it helps to understand the objects involved:
The foreign data wrapper encapsulates the code to access the remote data source (PostgreSQL client).
The foreign server wraps the connect string for the remote database.
The user mapping contains the credentials for a user to access the foreign server.
The foreign table describes a table on the remote server.
You can use the command IMPORT FOREIGN SCHEMA to automatically define foreign tables for all (or part) of the tables in a schema on the remote server.
Once the foreign tables are defined correctly, you can use them in SQL statements just like local tables, but you will actually read and write data on the remote server.
After some debugging, the problem turned out to be this:
Creating the foreign server using pgAdmin caused a strange error with fsrvoption (running CREATE SERVER via the query tool worked).
Creating the foreign server with localhost rather than the correct server address unsurprisingly gave the error that the database doesn't exist.
I had a foreign table set up in Postgres 10. The role "role1" has been granted usage on the foreign server (fs) that was set up using the postgres superuser.
I imported the table using the import schema command:
IMPORT FOREIGN SCHEMA f_schema LIMIT TO (my_fdw_table) FROM fs INTO ls;
That worked fine.
However, when I try to query the table I get the following error:
SELECT * FROM my_fdw_table LIMIT 1;
ERROR: permission denied for view my_fdw_table
CONTEXT: remote SQL command: ...
My understanding is that FDW should treat views and tables the same.
It looks like the remote user that you used in the user mapping for your local user and the foreign server does not have the required permissions on the table (or the schema that contains it).
User "role1" should create user mapping for itself like:
CREATE USER MAPPING FOR role1 SERVER fs OPTIONS (USER 'role1', PASSWORD 'password1');
IMPORT FOREIGN SCHEMA f_schema LIMIT TO (my_fdw_table) FROM SERVER fs INTO ls;
Also, if "role1" is not an owner of the database, it should get access from its owner:
GRANT USAGE ON SCHEMA ls TO role1;
Assuming ls is local schema.
Could somebody help me understand how I would go about setting up postgresql's mysql_fdw? I'm looking at https://github.com/EnterpriseDB/mysql_fdw, and I not sure what the first step is.
I was able to do it the following way.
Installing the package:
sudo apt-get install postgresql-9.5-mysql-fdw
Adds the extension in the Database:
CREATE EXTENSION mysql_fdw;
Add the mysql server to postgresql:
CREATE SERVER mysql_server FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'localhost', port '3306');
Create a user to access the database:
CREATE USER MAPPING FOR postgres SERVER mysql_server OPTIONS (username 'root', password 'passwordToConnect');
Import a Schema table from another server
IMPORT FOREIGN SCHEMA mySchema LIMIT TO (tableName) FROM SERVER mysql_server INTO public;
Imports all Schema tables from another server
IMPORT FOREIGN SCHEMA mySchema FROM SERVER mysql_server INTO public;
I hope I have helped.
You linked to the ODBC foreign data wrapper odbc_fdw. You can use it for MySQL, but if you just want MySQL you should use mysql_fdw instead. That way you don't have to mess with ODBC.
Handily, the README for mysql_fdw contains detailed instructions for installation and configuration, so you should be fine setting it up; I won't duplicate those instructions here.