From: | Rui DeSousa <rui(dot)desousa(at)icloud(dot)com> |
---|---|
To: | Luis Marin <luismarinaray(at)gmail(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Ideas to deal with table corruption |
Date: | 2018-01-06 18:16:47 |
Message-ID: | B197BCE8-07E4-4FEE-A5DD-D0917A8BC10A@icloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
How large are the given tables and is the databases in heavy use at the time? It sounds like either blocking is occurring or you’re dealing with large tables and the validation is take a long time; which, in both case is normal.
Try creating the foreign key without validation, i.e. use the “not valid” clause. That will create the foreign key and start to enforce it; however, existing data may not conform thus Postgres will report it as not valid. Then you can validate the foreign key which occurs concurrently. This is the approach I use on live production systems to avoid blocking issues.
i.e.:
alter table member_outline
add constraint member_outline_fkey1
foreign key (dimension, member) references member(dimension, member)
on update cascade not valid
;
alter table member_outline
validate constraint member_outline_fkey1
;
Nothing that you stated points to any table corruption.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-01-06 18:23:40 | Re: Ideas to deal with table corruption |
Previous Message | Adrian Klaver | 2018-01-06 17:39:59 | Re: Ideas to deal with table corruption |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-01-06 18:23:40 | Re: Ideas to deal with table corruption |
Previous Message | Adrian Klaver | 2018-01-06 17:39:59 | Re: Ideas to deal with table corruption |