Re: Inconsistency in determining the timestamp of the db statfile.

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Inconsistency in determining the timestamp of the db statfile.
Дата
Msg-id CABUevExYSL1POqSPfZ=sd+ab9qd9s0jX+ApX7+51otX3gfOW6w@mail.gmail.com
обсуждение исходный текст
Ответ на Inconsistency in determining the timestamp of the db statfile.  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Inconsistency in determining the timestamp of the db statfile.
Список pgsql-hackers
Дерево обсуждения


On Tue, Sep 8, 2020 at 8:10 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
We use the timestamp of the global statfile if we are not able to
determine it for a particular database either because the entry for
that database doesn't exist or there is an error while reading the
specific database entry. This was not taken care of while reading
other entries like ArchiverStats or SLRUStats. See
pgstat_read_db_statsfile_timestamp. I have observed this while
reviewing Sawada-San's patch related to logical replication stats [1].

I think this can only happen if due to some reason the statfile got
corrupt or we
have some bug in stats writing code, the chances of both are rare and even
if that happens we will use stale statistics.

The attached patch by Sawada-San will fix this issue. As the chances of this
the problem is rare and nobody has reported any issue related to this,
so it might be okay not to backpatch this.

Thoughts?


Why are we reading the archiver statis and and slru stats in "pgstat_read_db_statsfile_timestamp" in the first place? That seems well out of scope for that function.

If nothing else the comment at the top of that function is out of touch with reality. We do seem to read it into local buffers and then ignore the contents. I guess we're doing it just to verify that it's not corrupt -- so perhaps the function should actually have a different name than it does now, since it certainly seems to do more than actually read the statsfile timestamp.

Specifically in this patch it looks wrong -- in the case of say the SLRU stats being corrupt, we will now return the timestamp of the global stats file even if there is one existing for the database requested, which definitely breaks the contract of the function. It's already broken, but this doesn't seem to make it less so.

--

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

Предыдущее
От: "Andrey V. Lepikhov"
Дата:
Сообщение: Re: [POC] Fast COPY FROM command for the table with foreign partitions
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: INSERT ON CONFLICT and RETURNING