Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |
Дата | |
Msg-id | 20220314.173000.398225758850773114.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
|
Список | pgsql-bugs |
At Mon, 14 Mar 2022 17:12:18 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in > On Sat, Mar 12, 2022 at 4:53 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > Masahiko Sawada <sawada.mshk@gmail.com> writes: > > > I've attached a draft patch for discussion. > > > > Hm, I think that trying to RESET a GUC_NO_RESET variable ought to > > actively throw an error. Silently doing nothing will look like > > a bug. > > Agreed. I've attached an updated patch. FWIW, + /* Check if the parameter supports RESET */ + if (record->flags & GUC_NO_RESET && value == NULL) + { + ereport(elevel, + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), + errmsg("parameter \"%s\" cannot be reset", + name))); ERRCODE_FEATURE_NOT_SUPPORTED doesn't look proper for the case. Isn't it ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE or something like? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-bugs по дате отправления: