Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end - Mailing list pgsql-bugs

From Kyotaro Horiguchi
Subject Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Date
Msg-id 20220315.113333.1974856655620066857.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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



pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #17255: Server crashes in index_delete_sort_cmp() due to race condition with vacuum
Next
From: PG Bug reporting form
Date:
Subject: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE