I'm importing millions of rows from different files.
One of those files throws an exception about a constraint:
PG::InternalError: ERROR: constraint 109531 is not a foreign key constraint (ActiveRecord::StatementInvalid)
How can I find the constrain 109531?
I can't find it on pg_constraint ...
Where I should look?
EDIT:
The error comes directly from PostgreSQL, Activerecord is passing it.
After adding a parent row manually using psql, now if I want to delete or update the row, I'm getting a new constrain error:
ERROR: constraint 109529 is not a foreign key constraint
If I try to find the constrain:
select * FROM pg_constraint;
I can see lots of constraints with similar numbers:
107878,109309,109521
Only with
TRUNCATE table CASCADE;
the row has been deleted
Well, after deleting ALL constraints and recreating them (with methods as there are more than 200 constraints), everything works perfect ...
I've used this link for the automated generated/removed constraints
Related
We are using postgres Aurora RDS ( version 12.4)
We have a table on which we had a unique constraint on three columns (Column_a , column_b, column_c). After some time ,we realized we would need to add one more column to the unique constraint while the table already had some data.
So we decided to drop the constraint and recreate it with the new set of columns. The following are the statements used:
alter table table_name drop constraint constraint_name ;
ALTER TABLE ONLY table_name
ADD unique constraint constraint_name ( column_new ,column_a, column_b , column_c) ;
After recreating the constraint the constraint is shown as invalid and on conflict statements using this constraint are failing with an error message:
"there is no unique or exclusion constraint matching the ON CONFLICT specification"
We tried creating a duplicate table . We could not replicate the problem when this backup table had no data . But on filling in some data into the table and trying the same steps we could replicate the problem . The new constraint was showing as invalid .
We would like to understand what causes the constraint to be invalid. Is there any restriction on dropping constraints on tables already having data? We would like to know if we could overcome this without truncating the table.
I have a table named base_types that contains this constraint:
ALTER TABLE public.base_types
ADD CONSTRAINT base_type_gas_type_fk FOREIGN KEY (gas_type)
REFERENCES public.gas_types (gas_type) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED;
And I have a table named alarm_history that contains five constraints, including this one:
ALTER TABLE public.alarm_history
ADD CONSTRAINT alarm_history_device_fk FOREIGN KEY (device)
REFERENCES public.bases (alarm_device) MATCH SIMPLE
ON UPDATE NO ACTION
ON DELETE NO ACTION
DEFERRABLE INITIALLY DEFERRED;
I am trying to convert a database from one that didn't bother with anything weird and useless like constraints into one that uses them. I am beginning with this script:
delete from gas_types;
select conversion.convert_base_types();
alter table base_types validate constraint base_type_gas_type_fk;
select conversion.convert_alarm_history();
alter table alarm_history validate constraint alarm_history_base_fk;
alter table alarm_history validate constraint alarm_history_charge_fk;
alter table alarm_history validate constraint alarm_history_cooler_fk;
alter table alarm_history validate constraint alarm_history_device_fk;
alter table alarm_history validate constraint alarm_history_furnace_fk;
I duly get an error message telling me that the gas_type field in my new base_types record doesn't match anything in the gas_types table, since the gas_types table is empty. But if I comment out the base_types commands, I get 18,000 nice, shiny new records in the alarm_history table, despite the fact that every single one of them violates at least one of that table's five foreign key constraints, since all of the tables those keys are referring to are empty. I need to ensure that my converted data is consistent, and therefore I need to validate my constraints, but that's obviously not happening. Why not?
Since the constraints above are created as DEFERRABLE INITIALLY DEFERRED, they are not checked until the DML statements (your delete statement) are committed or in your case you until you explicitly validate the constraint.
This is the normal and expected operation of an initially deferred deferrable constraint.
To change this functionality within your current transaction you can issue a SET CONSTRAINTS command to alter this:
SET CONSTRAINTS alarm_history_device_fk IMMEDIATE;
delete from gas_types;
Which should raise a foreign key violation alerting you earlier that you have data dependent on the records you are tying to delete.
When dropping constraints from a postgres table , How to know the safest order to drop the constraints. Like ,
1) The foreign key constraints can be dropped first [as they have to be droppped before primary key constraint]
Then the order of removing the constraints can be in any order . like check constraint, unique constraint, not nulls, default , primary key constraints . Am I correct
No constraint on a PostgreSQL table depends on another constraint on the same table, so the order does not matter here.
The only dependency between constraints is the dependency of a foreign key on the primary or unique key on the target table.
So you can either remove all foreign key constraints first and then all other constraints, or you can use ALTER TABLE ... DROP CONSTRAINT ... CASCADE which will automatically drop all dependent constraints, then you don't have to care about the order at all.
I searched for this problem. But my postgres user has enough grant and I do not think I have misspelling error. However I am newbie.
I have this error message:
21:38:03 set search_path='public'
21:38:03 ALTER TABLE public.tbl_user DROP CONSTRAINT "fk-user-access-user-id"
21:38:03 ERROR: constraint "fk-user-access-user-id" of relation "tbl_user" does not exist
I use the PhpStorm. I just open the database view, expanded the tbl_user table, right click and select "drop". And I got this error in the console.
So the above SQL command generated by the PhpStorm.
Then I tried with these commands manually on Ubuntu:
ALTER TABLE tbl_user DROP CONSTRAINT "fk-user-access-user-id"
ALTER TABLE "tbl_user" DROP CONSTRAINT "fk-user-access-user-id"
But I get the same error.
In the PhpStorm I see this definition:
"fk-user-access-user-id" FOREIGN KEY (access_id) REFERENCES tbl_access (id)
The tbl_access table exists with the primary id key.
I do not understand this error message, because the "fk-user-access-user-id" foreign key is at the tbl_user and so for me the 'relation "tbl_user" does not exist' strange. I do not understand.
I tried to find similar problem on StackOverflow, but I gave up after 20x question reading.
By the way, the postgres code was generated by the Yii framework.
$this->addColumn('{{%user}}', 'access_id', $this->integer()->notNull()->defaultValue(1)->after('status'));
$this->addForeignKey('fk-user-access-user-id', '{{%user}}', 'access_id', '{{%access}}', 'id');
first row mean add access_id column to the user table.
second row: create foreign key with 'fk-user...' name on tbl_user table's access_id column references to tbl_access table's id column.
So I used this PHP code to generate this SQL commands. I prefer this way because for me the migration files are very useful.
Most likely the definition and actual implementation in your underlying DB has changed from what the app has recorded. Depending on what the history is, either a change in the app for that foreign key relationship was not migrated to persist the change at the database level, or someone has executed some operation directly at the DB level to remove the relationship. You will need to sync up the app layer to the DB at this point I would think.
There is an empty table called ADDRESS.
I perform DELETE FROM ADDRESS and everything is OK.
There is another empty called ADDRESSMAPPING.
Now I add a foreign key constraint to ADDRESSMAPPING which references ADDRESS.
ALTER TABLE ADDRESSMAPPING
ADD CONSTRAINT FK_ADDRESSMAPPING_ADRESS_ID
FOREIGN KEY (ADDRESS_ID) REFERENCES ADDRESS
When I then perform DELETE FROM ADDRESS the following error occurs:
[55019][-7008] [SQL7008] ADDRESS in MY_SCHEMA not valid for the
operation
Both mentioned tables are still empty. If I remove the constraint the DELETE statement terminates again properly.
Why does this error occur? And how can I fix it?
Described problem occurs because the tables are not journaled. Adding journaling to the tables should solve the problem.