Re: ACCESS EXCLUSIVE lock
От | Atesz |
---|---|
Тема | Re: ACCESS EXCLUSIVE lock |
Дата | |
Msg-id | 4537812A.3060408@ritek.hu обсуждение исходный текст |
Ответ на | Re: ACCESS EXCLUSIVE lock (Scott Marlowe <smarlowe@g2switchworks.com>) |
Список | pgsql-performance |
Scott Marlowe wrote: > What if, a minute or two after the drop contraint, you issue a rollback? > After the DROP CONSTRAINT I insert 4 million rekords into the TABLE b. After the inserts I remake the dropped constraints, and commit the transaction (P1). This solution is faster then the conventional method without the constraint's trick. In my work the table A is a dictionary table (key-value pairs) with 100-200 records, and the TABLE b has 20 columns with 10 references to TABLE a. So my experience is that I have to drop constraints before the 4 million inserts and remake those after it. If there is an error in my transaction (P1) and I have to rollback, there isn't problem, because my inserts lost from TABLE b and the dropped constraints may be rolled back. In my opinion there isn't exclusion between a dropped constraint (reference from b to a) and a select on TABLE a. If I think well the dropped constraint have to seem in other transation (for example: P2). And it doesn't have to seem in my transaction, because it has already dropped. Thanks your suggestions! Regards, Antal Attila
В списке pgsql-performance по дате отправления: