Re: Allowing REINDEX to have an optional name

Поиск
Список
Период
Сортировка
От Bernd Helmle
Тема Re: Allowing REINDEX to have an optional name
Дата
Msg-id 9832691be1eaad11583734603dc83f8d4f77bc6a.camel@oopsware.de
обсуждение исходный текст
Ответ на Allowing REINDEX to have an optional name  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список pgsql-hackers
Hi,

Am Dienstag, dem 10.05.2022 um 10:13 +0100 schrieb Simon Riggs:
> A minor issue, and patch.
>
> REINDEX DATABASE currently requires you to write REINDEX DATABASE
> dbname, which makes this a little less usable than we might like.
>
> REINDEX on the catalog can cause deadlocks, which also makes REINDEX
> DATABASE not much use in practice, and is the reason there is no test
> for REINDEX DATABASE. Another reason why it is a little less usable
> than we might like.
>
> Seems we should do something about these historic issues in the name
> of product usability.
>

Wow, i just recently had a look into that code and talked with my
colleagues on how the current behavior annoyed me last week....and
there you are! This community rocks ;)

> Attached patch allows new syntax for REINDEX DATABASE, without
> needing
> to specify dbname. That version of the command skips catalog tables,
> as a way of avoiding the known deadlocks. Patch also adds a test.
>

+        /* Unqualified REINDEX DATABASE will skip catalog
tables */
+        if (objectKind == REINDEX_OBJECT_DATABASE &&
+            objectName == NULL &&
+            IsSystemClass(relid, classtuple))
+            continue;

Hmm, shouldn't we just print a NOTICE or something like this in
addition to this check to tell the user that we are *not* really
reindexing all things (and probably give him a hint to use REINDEX
SYSTEM to cover them)?

    Thanks,
        Bernd




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

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Support logical replication of DDLs