Re: error context for vacuum to include block number

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: error context for vacuum to include block number
Дата
Msg-id CA+TgmoYSvEP3weQaCPGf6+DXLy2__JbJUYtoXyWP=qHcyGbihA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: error context for vacuum to include block number  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: error context for vacuum to include block number (atomicprogress update)  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Thu, Dec 26, 2019 at 10:57 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> I agree that's better.
> I don't see any reason why the progress params need to be updated atomically.
> So rebasified against your patch.

I am not sure whether it's important enough to make a stink about, but
it bothers me a bit that this is being dismissed as unimportant. The
problem is that, if the updates are not atomic, then somebody might
see the data after one has been updated and the other has not yet been
updated. The result is that when the phase is
PROGRESS_VACUUM_PHASE_VACUUM_INDEX, someone reading the information
can't tell whether the number of index scans reported is the number
*previously* performed or the number performed including the one that
just finished. The race to see the latter state is narrow, so it
probably wouldn't come up often, but it does seem like it would be
confusing if it did happen.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Consolidate 'unique array values' logic into a reusable function?