| От | Joachim Wieland |
|---|---|
| Тема | Re: TODO-Item: TRUNCATE ... CASCADE |
| Дата | |
| Msg-id | 20060205172404.GA2449@mcknight.de обсуждение исходный текст |
| Ответ на | Re: TODO-Item: TRUNCATE ... CASCADE (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: TODO-Item: TRUNCATE ... CASCADE
|
| Список | pgsql-patches |
On Fri, Feb 03, 2006 at 10:27:30AM -0500, Tom Lane wrote: > Basically: it's the user's fault if he says "TRUNCATE t2" in a situation > where the referent of t2 might be changing concurrently. But once > you've identified t2, it's your fault if you don't track the > dependencies of t2 correctly, even if someone else is busy renaming them. Ok, the attached patch now does it correctly as suggested by Alvaro. For code simplicity I changed the locking order of the tables in the RESTRICT-case as well. Before they got locked and then checked one by one. To simplify integration of the CASCADE-case however, I changed it to lock all - check all. So it is now: CASCADE: lock direct - add and lock cascaded tables - check all - truncate all RESTRICT: lock direct (= all) - check all - truncate all. Joachim
В списке pgsql-patches по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера