Re: deadlock in REINDEX
От | Gavin Sherry |
---|---|
Тема | Re: deadlock in REINDEX |
Дата | |
Msg-id | Pine.LNX.4.21.0302181206580.19114-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: deadlock in REINDEX (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: deadlock in REINDEX
|
Список | pgsql-hackers |
On Mon, 17 Feb 2003, Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > On Mon, 2003-02-17 at 18:39, Tom Lane wrote: > >> If you release the lock then I think you are opening yourself to worse > >> troubles than this one, having to do with someone renaming/deleting the > >> table and/or index out from under you. > > > Presumably, the renaming/deleting operation acquires an exclusive lock > > and then holds it until transaction commit, right? If so, then wouldn't > > we still be okay: the REINDEX would lock the index in access share mode, > > find the OID of the heap rel, unlock the index, lock the heap rel in > > access exclusive mode, then try to re-open & lock the index, find that > > it no longer exists and then elog(ERROR). > > That approach might be deadlock-free, but that doesn't mean it is > surprise-free. For example, if the other guy did an ALTER TABLE RENAME Perhaps the change that needs to be made is: if(IsUnderPostmaster)elog(ERROR,"You cannot run REINDEX INDEX in multi-user mode"); to ReindexIndex() or some other appropriate place (with a better error message). Gavin
В списке pgsql-hackers по дате отправления: