Re: Hot standby and b-tree killed items
От | Simon Riggs |
---|---|
Тема | Re: Hot standby and b-tree killed items |
Дата | |
Msg-id | 1229717380.4793.617.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Hot standby and b-tree killed items ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Hot standby and b-tree killed items
|
Список | pgsql-hackers |
On Fri, 2008-12-19 at 13:47 -0600, Kevin Grittner wrote: > >>> Simon Riggs <simon@2ndQuadrant.com> wrote: > > > max_standby_delay is set in recovery.conf, value 0 (forever) - > 2,000,000 > > secs, settable in milliseconds. So think of it like a deadlock > detector > > for recovery apply. > > Aha! A deadlock is a type of serialization failure. (In fact, on > databases with lock-based concurrency control rather than MVCC, it can > be the ONLY type of serialization failure.) The SQL Standard specifically names this error as thrown when "it detects the inability to guarantee the serializability of two or more concurrent SQL-transactions". Now that really should only apply when running with SERIALIZABLE transactions, but I grant you the standard doesn't explicitly say that. You give me the strange sense that you want this because of some quirk in your software, rather than an overwhelming desire to see these two situations described the same. I guess making it that SQLSTATE would make it simpler to understand why the error occurs and also how to handle it (i.e. resubmit). So there probably is a wide argument for making developers jobs a little easier by doing it. i.e. usability will be improved if we do that. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: