On Tue, 26 Nov 2024 at 11:34, Shayon Mukherjee <shay...@gmail.com> wrote: > Thank you for the guidance and tips. I was wondering if updating in-place is > preferable or not, since my first instinct was to avoid it. I did not notice > any breakage last time, unless I was looking in the wrong place (possibly?). > I did 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 is a 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
