Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch) - Mailing list pgsql-hackers

From David Rowley
Subject Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)
Date
Msg-id CAApHDvqNjTUc3JUyGA26706_zBzaPenj1O0DbfKjLbPoAs+hnA@mail.gmail.com
Whole thread Raw
In response to Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)  (Shayon Mukherjee <shayonj@gmail.com>)
List pgsql-hackers
On Tue, 26 Nov 2024 at 11:34, Shayon Mukherjee <shayonj@gmail.com> wrote:
> Thank you for the guidance and tips. I was wondering if updating in-place is preferable or not, since my first
instinctwas to avoid it. I did not notice any breakage last time, unless I was looking in the wrong place (possibly?).
Idid notice the min update when a not-in-place update was performed, but I didn't notice any issues (as mentioned in
[1])from it, via logs, index usage, or other common operations. Let me write up some more test cases to check if there
isa risk of indexcheckxmin running out or other issues, and I'll get back here. 

Another safer option could be to disallow the enable/disable ALTER
TABLE if indcheckxmin is true. We do have and use
ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE for these sorts of issues.
There are other existing failure modes relating to indexes that can
depend on what another session has done, e.g. MarkInheritDetached()
can fail if another session detached an index concurrently. I could
respect an argument that this one might be worse than that as its
timing dependent rather than dependent on what another session has
done.

David



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE
Next
From: Tom Lane
Date:
Subject: Re: Self contradictory examining on rel's baserestrictinfo