Re: serializable read only deferrable
От | Kevin Grittner |
---|---|
Тема | Re: serializable read only deferrable |
Дата | |
Msg-id | 4CFF8A83020000250003847F@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: serializable read only deferrable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: serializable read only deferrable
Re: serializable read only deferrable |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > One thing to watch for is allowing subxact exit to restore the > previous read-write state. OK. > BTW it looks like assign_XactIsoLevel emits a rather useless debug > message in that case, so that code could stand some cleanup too. I'll take a look. > Also, that code is set so that it will throw an error even if > you're assigning the currently active setting, which maybe is > overly strict? Not sure. The standard is tricky to read, but my reading of it is that only "LOCAL" changes are allowed after the transaction is underway (which I *think* effectively means a subtransaction), and those can't make the setting less strict -- you're allowed to specify the same level or more strict. There would be no harm from the perspective of anything I'm working on to allow an in-progress transaction to be set to what it already has, but that seems to invite confusion and error more than provide a helpful feature, as far as I can tell. I'm inclined not to allow it except at the start of a subtransaction, but don't feel strongly about it. >> I can fix up the patch if to support it again if you like. > Feel free to have a go at it. Will do. I notice that I also removed the check for RecoveryInProgress(), which I will also restore. And maybe a regression test or two for the subtransaction usages.... -Kevin
В списке pgsql-hackers по дате отправления: