| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | sawada(dot)mshk(at)gmail(dot)com, d(dot)koval(at)postgrespro(dot)ru, dilipbalaut(at)gmail(dot)com, andrewbille(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |
| Date: | 2022-03-14 13:45:17 |
| Message-ID: | 170696.1647265517@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2022-03-14 17:30:25 | BUG #17438: Logical replication hangs on master after huge DB load |
| Previous Message | Kyotaro Horiguchi | 2022-03-14 08:30:00 | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |