Re: SIREAD lock versus ACCESS EXCLUSIVE lock

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: SIREAD lock versus ACCESS EXCLUSIVE lock
Дата
Msg-id 4DE92BE4.6000704@enterprisedb.com
обсуждение исходный текст
Ответ на Re: SIREAD lock versus ACCESS EXCLUSIVE lock  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: SIREAD lock versus ACCESS EXCLUSIVE lock  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: SIREAD lock versus ACCESS EXCLUSIVE lock  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: SIREAD lock versus ACCESS EXCLUSIVE lock  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Domains versus polymorphic functions, redux
Следующее
От: Peter Eisentraut
Дата:
Сообщение: permissions of external PID file