| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] SQL assertions prototype |
| Date: | 2013-12-18 19:22:28 |
| Message-ID: | 20131218192228.GC26481@alap2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2013-12-18 19:26:50 | Re: [PATCH] SQL assertions prototype |
| Previous Message | Andres Freund | 2013-12-18 19:17:44 | Re: 9.3 regression with dbt2 |