During development of a PostgreSQL database, I made foreign keys in every table. The problem is that I forgot to select ON DELETE CASCADE option.
I need to set that options on all tables. It seems I can only drop and recreate every constraint manually.
Does anybody know any shortcuts?
Update the constraints directly in pg_constraint. First get the oid's you need:
SELECT oid,* FROM pg_constraint WHERE contype = 'f';
And then update these constraints:
UPDATE pg_constraint SET confupdtype = 'c' WHERE oid = 'fk oid';
More information can be found in the manual. Please do this work within a transaction and do some tests within the transaction as well. Just to be sure.
You could use something like liquibase (http://www.liquibase.org/) which gives you essentially versioned DB schema's, and then it would be really simple to add constraints.
Of course this is serious overkill for this particular problem, but it does attempt to solve the issues on why you had this problem in the first place.
Related
We have a Postgresql database table with many tables. All of the tables seem to be functioning perfectly except for 1. In the last day or two it has stopped performing row deletes. When we try something simple like
delete from bad_table where id_foo = 123;
It acts as if it has successfully deleted the row. But when we do
select * from bad_table where id_foo = 123;
the row is still there.
The same type of queries work fine on all the other tables we tried.
In addition, the foreign keys on this table are not working. There is a foreign key constraint on a column that references a different table. There is an id in the "bad_table", but that id does not exist in the referenced table. Again, foreign key constraints appear to be working fine in all other tables, it is just this one. We tried dropping and recreating the foreign key (which seemed to be successful), but it had no effect.
Between my coworkers and myself we probably have 80 years of relational database experience across oracle, sql server, postgres, etc. and none of us has ever seen anything like this. We've been banging our heads against a wall and are now reaching out to the wider world to see if anyone has any ideas of what we could try. Has anyone else ever seen something like this in Postgres?
It turned out that the issue with foreign keys was solved by dropping the foreign key constraint and then immediately adding it again.
The issue with not being able to delete rows was fixed by dropping a trigger than was called on row delete and then immediate recreating the same trigger.
I don't know what happened, but it is acting like a constraint and a trigger on that particular table were corrupted.
I am looking for a way to add on delete cascade to all foreign keys in my PostgreSQL database (preferably limitable to a schema). I have found a script here, but it doesn't seem to work for PostgreSQL. The solution doesn't have to use a script, a GUI tool would also be fine.
Thank you.
The recommended and supported way to do this is to add new constraints with the same definition and ON DELETE CASCADE, then drop the original constraints.
If you are ready to risk breaking your database with a catalog modification, and you trust a random SQL statement from the internet, you could try
WITH tables(oid) AS (
UPDATE pg_constraint
SET confdeltype = 'c'
WHERE contype = 'f'
AND confdeltype <> 'c'
AND connamespace = 'myschema'::regnamespace
RETURNING confrelid
)
UPDATE pg_trigger
SET tgfoid = '"RI_FKey_cascade_del"()'::regprocedure
FROM tables
WHERE tables.oid = pg_trigger.tgrelid
AND tgtype = 9;
Test well before using!
I am creating a table in Postgresql 9.5 where id is the primary key. While inserting rows in the table if anyone tries to insert duplicate id, i want it to get ignored instead of raising exception. Is there any way such that i can set this while table creation itself that duplicate entries get ignored.
There are many techniques to resolve duplicate insertion issue while writing insertion query i.e. using ON CONFLICT DO NOTHING, or using WHERE EXISTS clause etc. But i want to handle this at table creation end so that the person writing insertion query doesn't need to bother any.
Creating RULE is one of the possible solution. Are there other possible solutions? Maybe something like this:
`CREATE TABLE dbo.foo (bar int PRIMARY KEY WITH (FILLFACTOR=90, IGNORE_DUP_KEY = ON))`
Although exact this statement doesn't work on Postgresql 9.5 on my machine.
add a trigger before insert or rule on insert do instead - otherwise has to be handled by inserting query. both solutions will require more resources on each insert.
Alternative way to use function with arguments for insert, that will check for duplicates, so end users will use function instead of INSERT statement.
WHERE EXISTS sub-query is not atomic btw - so you can still have exception after check...
9.5 ON CONFLICT DO NOTHING is the best solution still
I have a problem encountered lately in our Postgres database, when I query: select * from myTable,
it results to, 'could not open relation with OID 892600370'. And it's front end application can't run properly anymore. Base on my research, I determined the column that has an error but I want exactly to locate the rows OID of the column so that I can modify it. Please help.
Thank you in advance.
You've got a corrupted database. Might be a bug, but more likely bad hardware. If you have a recent backup, just use that. I'm guessing you don't though.
Make sure you locate any backups of either the database or its file tree and keep them safe.
Stop the PostgreSQL server and take a file backup of the entire database tree (base, global, pg_xlog - everything at that level). It is now safe to start fiddling...
Now, start the database server again and dump tables one at a time. If a table won't dump, try dropping any indexes and foreign-key constraints and give it another go.
For a table that won't dump, it might be just certain rows. Drop any indexes and dump a range of rows using COPY ... SELECT. That should let you narrow down any corrupted rows and get the rest.
Now you have a mostly-recovered database, restore it on another machine and take whatever steps are needed to establish what is damaged/lost and what needs to be done.
Run a full set of tests on the old machine and see if anything needs replacement. Consider whether your monitoring needs improvement.
Then - make sure you keep proper backups next time, that way you won't have to do all this, you'll just use them instead.
could not open relation with OID 892600370
A relation is a table or index. A relation's OID is the OID of the row in pg_class where this relation is defined.
Try select relname from pg_class where oid=892600370;
Often it's immediately obvious from relname what this relation is, otherwise you want to look at the other fields in pg_class: relnamespace, relkind,...
Very quick and simple question. I am running a script to import data and have declared a temp table and applied check constraints to that table. Obviously if the script is run more than once I check whether the temp table already exists and if so, I drop and recreate the temp table. would that also drop and recreate the check constraints I placed on the temp table?
Logic says yes but I have been known to be wrong about such things.
Yes - dropping the temp table will drop any internal dependencies as well, including your constraints.
Yes, dropping the table will drop constraints, indexes etc that you may have created on it.
Also, if this is something you're doing repeatedly you may want to truncate it instead of drop/recreate it - that is typically a lot faster. (And sometimes, creating a "permanent" temp table can be a good idea for frequently occuring ops)