Re: Perfomance decreasing
От | Hiroshi Inoue |
---|---|
Тема | Re: Perfomance decreasing |
Дата | |
Msg-id | 3B7C849C.C0A452BD@tpf.co.jp обсуждение исходный текст |
Ответ на | RE: Re[2]: Perfomance decreasing ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: Perfomance decreasing
|
Список | pgsql-general |
Tom Lane wrote: > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > >> Hmmm ... it looks like REINDEX only grabs AccessShareLock on the target > >> relation, which seems very wrong. > > > Sorry I couldn't find where AccessShareLock is grabbed now. > > AccessExclusiveLock is acquired in reindex_index but do you > > mean it's too late ? > > I was looking at reindex_relation, which doesn't seem to grab anything > higher than AccessShareLock at all. But in any case, I think you should > be holding a lock on the parent table a lot sooner than you do, and > should not release it until transaction commit. reindex_relation ought > to be holding some lock on the table from the very start, IMHO. OK I don't object to it. > Maybe > AccessExclusiveLock is more than is needed, but I'd want to see a good > argument that it's safe not to hold an exclusive lock while you're doing > this stuff. What happens if two backends try to REINDEX at the same time? One backend would be blocked by another one because reindex_relation calls reindex_index and reindex_index grabs an ExclusiveLock on the relation. Am I missing anything ? regards, Hiroshi Inoue > > regards, tom lane
В списке pgsql-general по дате отправления: