Re: Support for REINDEX CONCURRENTLY
От | Jim Nasby |
---|---|
Тема | Re: Support for REINDEX CONCURRENTLY |
Дата | |
Msg-id | 50735ECE.6060101@nasby.net обсуждение исходный текст |
Ответ на | Re: Support for REINDEX CONCURRENTLY (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Support for REINDEX CONCURRENTLY
|
Список | pgsql-hackers |
On 10/8/12 6:12 PM, Tom Lane wrote: > Jim Nasby <jim@nasby.net> writes: >> Yeah, what's the risk to renaming an index during concurrent access? > > SnapshotNow searches for the pg_class row could get broken by *any* > transactional update of that row, whether it's for a change of relname > or some other field. > > A lot of these problems would go away if we rejiggered the definition of > SnapshotNow to be more like MVCC. We have discussed that in the past, > but IIRC it's not exactly a simple or risk-free change in itself. > Still, maybe we should start thinking about doing that instead of trying > to make REINDEX CONCURRENTLY safe given the existing infrastructure. Yeah, I was just trying to remember what other situations this has come up in. My recollection is that there's been a coupleother cases where that would be useful. My recollection is also that such a change would be rather large... but it might be smaller than all the other work-aroundsthat are needed because we don't have that... -- Jim C. Nasby, Database Architect jim@nasby.net 512.569.9461 (cell) http://jim.nasby.net
В списке pgsql-hackers по дате отправления: