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(at)cs(dot)toronto(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)cs(dot)toronto(dot)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(at)sss(dot)pgh(dot)pa(dot)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