Re: SIREAD lock versus ACCESS EXCLUSIVE lock
От | Kevin Grittner |
---|---|
Тема | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
Дата | |
Msg-id | 4DE8EB89020000250003E112@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: SIREAD lock versus ACCESS EXCLUSIVE lock (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: SIREAD lock versus ACCESS EXCLUSIVE lock
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > On 03.06.2011 21:04, Kevin Grittner wrote: >> Also, if anyone has comments or hints about the placement of >> those calls, I'd be happy to receive them. > > heap_drop_with_catalog() schedules the relation for deletion at > the end of transaction, but it's still possible that the > transaction aborts and the heap doesn't get dropped after all. If > you put the DropAllPredicateLocksFromTable() call there, and the > transaction later aborts, you've lost all the locks already. > > I think you'll need to just memorize the lock deletion command in > a backend-local list, and perform the deletion in a post-commit > function. Something similar to the PendingRelDelete stuff in > storage.c. In fact, hooking into smgrDoPendingDeletes would work, > but that seems like a modularity violation. Thanks. That's helpful. Will look at that code and do something similar. I knew it didn't look right in the place it was, but couldn't quite see what to do instead.... -Kevin
В списке pgsql-hackers по дате отправления: