Re: Serializable snapshot isolation error logging
От | Dan S |
---|---|
Тема | Re: Serializable snapshot isolation error logging |
Дата | |
Msg-id | AANLkTinA2r1g4tSHyEo1FMF+VduQwk-m63VB9T2WmYey@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Serializable snapshot isolation error logging ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Serializable snapshot isolation error logging
|
Список | pgsql-hackers |
<br />A starvation scenario is what worries me:<br /><br />Lets say we have a slow complex transaction with many tables involved.<br/>Concurrently smaller transactions begins and commits .<br /><br />Wouldn't it be possible for a starvationscenario where the slower transaction will<br /> never run to completion but give a serialization failure overand over again on retry ?<br /><br />If I know at what sql-statement the serialization failure occurs can i then concludethat <br />some of the tables in that exact query were involved in the conflict ?<br /><br />If the serializationfailure occurs at commit time what can I conclude then ?<br />They can occur at commit time right ?<br /><br/>What is the likelyhood that there exists an update pattern that always give the failure in the slow transaction ?<br/><br />How would one break such a recurring pattern ?<br />You could maybe try to lock each table used in the slow transactionbut that would be prohibitively costly<br />for concurrency.<br />But what else if there is no way of knowingwhat the slow transaction conflicts against.<br /><br />As things with concurrency involved have a tendency to popup in production and not in test I think it is important to<br />start thinking about them as soon as possible.<br /><br/>Best Regards<br />Dan S<br /><br />
В списке pgsql-hackers по дате отправления: