Re: recovering from "found xmin ... from before relfrozenxid ..." - Mailing list pgsql-hackers

From Robert Haas
Subject Re: recovering from "found xmin ... from before relfrozenxid ..."
Date
Msg-id CA+TgmobtaxTGFNLfFQFk5j20nSH_BsZh4rQwy-jt90qK4PQGoA@mail.gmail.com
Whole thread Raw
In response to Re: recovering from "found xmin ... from before relfrozenxid ..."  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: recovering from "found xmin ... from before relfrozenxid ..."  (Ashutosh Sharma <ashu.coek88@gmail.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: LWLockAcquire and LockBuffer mode argument
Next
From: Robert Haas
Date:
Subject: Re: LWLockAcquire and LockBuffer mode argument