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

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

            regards, tom lane



pgsql-bugs by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
Next
From: PG Bug reporting form
Date:
Subject: BUG #17438: Logical replication hangs on master after huge DB load