Re: [PATCH] SQL assertions prototype
От | Alvaro Herrera |
---|---|
Тема | Re: [PATCH] SQL assertions prototype |
Дата | |
Msg-id | 20131218193958.GF11006@eldon.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [PATCH] SQL assertions prototype (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [PATCH] SQL assertions prototype
Re: [PATCH] SQL assertions prototype |
Список | pgsql-hackers |
Andres Freund wrote: > On 2013-12-18 13:44:15 -0300, Alvaro Herrera wrote: > > Heikki Linnakangas wrote: > > > > > Ah, I see. You don't need to block anyone else from modifying the > > > table, you just need to block anyone else from committing a > > > transaction that had modified the table. So the locks shouldn't > > > interfere with regular table locks. A ShareUpdateExclusiveLock on > > > the assertion should do it. > > > > Causing serialization of transaction commit just because a single > > assertion exists in the database seems too much of a hit, so looking for > > optimization opportunities seems appropriate. > > It would only force serialization for transactions that modify tables > covered by the assert, that doesn't seem to bad. Anything covered by an > assert shoulnd't be modified frequently, otherwise you'll run into major > performance problems. Well, as presented there is no way (for the system) to tell which tables are covered by an assertion, is there? That's my point. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: