Re: recovering from "found xmin ... from before relfrozenxid ..."

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: recovering from "found xmin ... from before relfrozenxid ..."
Дата
Msg-id CA+TgmobtaxTGFNLfFQFk5j20nSH_BsZh4rQwy-jt90qK4PQGoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: recovering from "found xmin ... from before relfrozenxid ..."  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Ответы Re: recovering from "found xmin ... from before relfrozenxid ..."  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Список pgsql-hackers
On Tue, Aug 25, 2020 at 8:17 AM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
> + <note>
> + <para>
> +  While performing surgery on a damaged relation, we must not be doing anything
> +  else on that relation in parallel. This is to ensure that when we are
> +  operating on a damaged tuple there is no other transaction trying to modify
> +  that tuple.
> + </para>
> + </note>
>
> If we prefer to avoid concurrent operations on the target relation why
> don't we use AccessExclusiveLock?

I disagree with the content of the note. It's up to the user whether
to perform any concurrent operations on the target relation, and in
many cases it would be fine to do so. Users who can afford to take the
table off-line to repair the problem don't really need this tool in
the first place.

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



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: LWLockAcquire and LockBuffer mode argument
Следующее
От: Robert Haas
Дата:
Сообщение: Re: LWLockAcquire and LockBuffer mode argument