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.
Related
I'm using Db2 11.5.4000.1449 on window 10.
I have the table THETABLE with those columns:
THEKEY CHAR(30) NOT NULL
THEDATA CHAR(30)
Primary key: THEKEY
I try to enlarge the primary key column using the following statement:
ALTER TABLE THETABLE ALTER COLUMN THEKEY SET DATA TYPE CHAR(50)
But I got the error:
SQLCODE=-668, SQLSTATE=57007 reason code="7"
The official IBM documentation says which the table is in reorg pending state
The table is NOT in reorg pending state.
I've check using:
SELECT REORG_PENDING FROM SYSIBMADM.ADMINTABINFO
where TABSCHEMA='DB2ADMIN' and tabname='THETABLE'
The results of the below query is: N
I've tried to reorg both the table and indexes but the problem persists.
The only way I have found is to drop the primary key, alter the column and then add the primary key.
Note:
I have also other tables in which I've enlarged a CHAR column which is a primary key. (without dropping and recreate the primary key)
The problems does not come for all tables but only for some tables.
I have no idea why for some table is possible to enlarge a CHAR column which is a primary and and for some other tables not.
Have you any idea?
I am trying to insert a new table into a big old table to update multiple rows ,
here is my query:
INSERT INTO site_settings (set_id, set_sit_id,set_setting_name,set_setting_type)
SELECT set_id, set_sit_id, replace(TempTable2.stp_device_pool_filter, '${siteShortName}', TempTable2.sit_short_name), set_setting_type from TempTable2 where set_setting_type='DEVICE_POOL'
ON CONFLICT (set_id) DO UPDATE
SET set_sit_id=excluded.set_sit_id,
set_setting_name=excluded.set_setting_name,
set_setting_type=excluded.set_setting_type;
it returns me the message:
duplicate key value violates unique constraint "unique_site_setting"
DETAIL: Key (set_sit_id, set_setting_name, set_setting_type)=(13, SBA123-rr, DEVICE_POOL) already exists.
However, I used to use the similar query to update a much more complicated table, it worked.
don't know what's the problem
I cannot drop a constraint in postgres even using adminer
ALTER TABLE table_name
DROP CONSTRAINT constraint_name;
Error in query : ERROR: constraint "constraint_name" of relation "table_name" does not exist
but if I create a new one like :
ALTER TABLE table_name
ADD CONSTRAINT my_new_constraint(column1, column2, ... column_n);
Then it works and I can drop it.
The one who made the constraint I try to drop did it this way two years ago:
create unique index constraint_name on table_name (column1,lower(column2),coalesce(deleted_at,\'19000101\')
If anyone has got any idea to drop this constraint?
CREATE UNIQUE INDEX creates an index that needs to be dropped with DROP INDEX, not a table constraint.
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
i am getting a unique constraint issue in postgresql while updating a table. I have a table with 3 columns and an unique constraint on one of the column(internal_state). This table will have only two columns and values for internal_state are 1,0.
The update query is
UPDATE backfeed_state SET internal_state = internal_state - 1
WHERE EXISTS (SELECT 1 FROM backfeed_state d2 WHERE d2.internal_state = 1 )
Running this query is fine in MSSqlserver but in postgre it is throwing unique constraint error.
What i understand is in SQLServer after updating all the rows then only constraint on the columns are checking but in postgre after updating each row, constraints are checking. So after updating the first row(internal_state value from 1 to 0) postgre is checking the constraint and throwing error even before updating the second row.
Is there a way to avoid this situation?
http://www.postgresql.org/docs/9.0/static/sql-createtable.html in section "Non-deferred Uniqueness Constraints" - "When a UNIQUE or PRIMARY KEY constraint is not deferrable, PostgreSQL checks for uniqueness immediately whenever a row is inserted or modified."
Changing your unique constraint to deferrable will hold off checking until the end of the update. Either use SET CONSTRAINTS to disable at the session level (which is annoyingly repetitive) or drop and re-create the uniqueness constraint with the deferrable option (I'm not aware of an ALTER construct to do that without dropping).