Re: Support for REINDEX CONCURRENTLY

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Support for REINDEX CONCURRENTLY
Дата
Msg-id CAB7nPqQyOz6-c6cAr8XJLqcJ-ooZO9mXtgiS0mqbCSzebFQEyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support for REINDEX CONCURRENTLY  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Support for REINDEX CONCURRENTLY
Список pgsql-hackers
Дерево обсуждения


On Tue, Mar 19, 2013 at 3:24 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
On Wed, Mar 13, 2013 at 9:04 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> I have been working on improving the code of the 2 patches:
> 1) reltoastidxid removal:
<snip>
> - Fix a bug with pg_dump and binary upgrade. One valid index is necessary
> for a given toast relation.

Is this bugfix related to the following?

        appendPQExpBuffer(upgrade_query,
-                                         "SELECT c.reltoastrelid, t.reltoastidxid "
+                                         "SELECT c.reltoastrelid, t.indexrelid "
                                          "FROM pg_catalog.pg_class c LEFT JOIN "
-                                         "pg_catalog.pg_class t ON (c.reltoastrelid = t.oid) "
-                                         "WHERE c.oid = '%u'::pg_catalog.oid;",
+                                         "pg_catalog.pg_index t ON (c.reltoastrelid = t.indrelid) "
+                                         "WHERE c.oid = '%u'::pg_catalog.oid AND t.indisvalid "
+                                         "LIMIT 1",
Yes.
 
Don't indisready and indislive need to be checked?
An index is valid if it is already ready and line. We could add such check for safely but I don't think it is necessary.

Why is LIMIT 1 required? The toast table can have more than one toast indexes?
It cannot have more than one VALID index, so yes as long as a check on indisvalid is here there is no need to worry about a LIMIT condition. I only thought of that as a safeguard. The same thing applies to the addition of a condition based on indislive and indisready.
--
Michael

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