Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end
От | Tom Lane |
---|---|
Тема | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |
Дата | |
Msg-id | 2735166.1644790175@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-bugs |
Hmm, here's a related anomaly: regression=# BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN regression=*# savepoint foo; SAVEPOINT regression=*# RESET transaction_isolation; RESET regression=*# select 1; ?column? ---------- 1 (1 row) regression=*# show transaction_isolation; transaction_isolation ----------------------- read committed (1 row) regression=*# rollback to foo; ROLLBACK regression=*# show transaction_isolation; transaction_isolation ----------------------- serializable (1 row) regression=*# commit; COMMIT I'm not sure why that didn't fail, but it seems like it should've: the commit-time isolation level is different from what we were using when we took the first snapshot. (Maybe we discard the snapshot state when rolling back? Not sure.) If we need to be sure that it's always okay to roll back a (sub)transaction, then that's an additional constraint on what's valid for GUCs to do. Yet it'd be a really bad idea to run check_hooks during transaction rollback, so maybe there's little choice. regards, tom lane
В списке pgsql-bugs по дате отправления: