Обсуждение: Do we force dependency?
How do we force the dependency according to pg_dependency records? Seems pg_dependency just records them and we follow the records by hand on create or delete ... Regards, Qingqing
Qingqing Zhou <zhouqq@cs.toronto.edu> writes: > How do we force the dependency according to pg_dependency records? Seems > pg_dependency just records them and we follow the records by hand on > create or delete ... Deletion scans the entries and either deletes the dependent objects or raises error. It's not "by hand" particularly, at least not for anything outside dependency.c. If you were to write code that deleted objects directly without going through the dependency mechanism, it wouldn't get accepted ;-) regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes > > Deletion scans the entries and either deletes the dependent objects or > raises error. It's not "by hand" particularly, at least not for > anything outside dependency.c. If you were to write code that deleted > objects directly without going through the dependency mechanism, it > wouldn't get accepted ;-) > The reason I raise this question is because I corrupted pg_trigger by concurrently perform drop/create table (with foreign keys). This was posted in pgbugs, but it is weird that I can't find out the original post. I suspect there are some race conditions in object deletion but not sure where: test=# select * from pg_trigger where tgconstrrelid not in (select oid from pg_class);tgrelid | tgname | tgfoid | tgtype | tgenabled | tgisconstraint | tgconstrname | tgconstrrelid | tgdeferrable | tginitdeferred | tgnargs| tgattr | tgargs ---------+----------------------------+--------+--------+-----------+------- ---- -----+----------------+---------------+--------------+----------------+----- ---- +--------+------------------------------------------------------------------ - 1260 | pg_sync_pg_pwd | 1689 | 29 | t | f | | 0 | f | f | 0 | | 1261 | pg_sync_pg_group | 1689 | 29 | t | f | | 0 | f | f | 0 | | 21598 | RI_ConstraintTrigger_21603 | 1644 | 21 | t | t | t_ds_col1_fkey | 21594 | f | f | 6 | | t_ds_col1_fkey\000t_ds\000t_wr\000UNSPECIFIED\000col1\000col1\000 (3 rows) Regards, Qingqing
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes: > The reason I raise this question is because I corrupted pg_trigger by > concurrently perform drop/create table (with foreign keys). That should be impossible because drop/create take out locks at the table level. Can you provide a reproducible test case? If you can't make it happen easily by hand, one possible way to proceed is to run one or both sessions under gdb and set breakpoints at key places like recursiveDeletion(). If there is a timing issue it should be possible to expose it by delaying a process at the right places in this way. regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes > > That should be impossible because drop/create take out locks at the > table level. Can you provide a reproducible test case? > To reproduce it: Concurrently execute the following sql script serveral times: ("without oids","tablespace testsp" should be optional) --- drop table T_ST; drop table T_IT; drop table T_DS; drop table T_WR; CREATE TABLE T_WR ( col1 int not NULL, primary key(col1)) without oids tablespace testsp ; CREATE TABLE T_DS ( col1 int not NULL, col2 int not NULL, primary key(col1, col2), foreign key (col1) references T_WR(col1)) without oids tablespace testsp ; CREATE TABLE T_IT ( col1 int not NULL, primary key(col1)) without oids tablespace testsp ; CREATE TABLE T_ST ( col1 int not null, col2 int not null, other_cols char (50) NULL , primary key(col1, col2), foreign key(col1) references T_WR(col1), foreign key(col2) references T_IT(col1)) without oids tablespace testsp ; --- Actually I reproduced it at least 3 times on Pg8.0.1. > If you can't make it happen easily by hand, one possible way to proceed > is to run one or both sessions under gdb and set breakpoints at key > places like recursiveDeletion(). If there is a timing issue it should > be possible to expose it by delaying a process at the right places in > this way. > Ok, I will do this and try to locate the exact place. Regards, Qingqing