Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end

At Mon, 14 Mar 2022 09:45:17 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > ERRCODE_FEATURE_NOT_SUPPORTED doesn't look proper for the case. Isn't
> > it ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE or something like?
> 
> Mmm ... I guess you could think of it that way, but it seems a
> little weird, because you have to suppose that the *transaction*
> not the GUC itself is the object that is in the wrong state.
> We could use ERRCODE_ACTIVE_SQL_TRANSACTION as is done in
> check_XactIsoLevel et al.  But this code is supposed to be generic,
> and if there are ever any other GUCs marked NO_RESET, who's to say
> if that would be appropriate at all for them?
> 
> I'm OK with FEATURE_NOT_SUPPORTED.

Hmm. Actually ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE is somewhat
strange since the error is not caused by some state of the object.  I
thought at the time that some error code like
ERRCODE_DOESNT_FOR_FOR_THIS_OBJECT but, yeah, finally
FEATURE_NOT_SUPPORTED looks fine after some additional thought.

Thanks.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center