From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(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 23:39:56 |
Message-ID: | 1387409996.72263.YahooMailNeo@web162905.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 12/18/2013 11:26 AM, Jim Nasby wrote:
>> Another possibility is to allow for two different types of
>> assertions, one based on SSI and one based on locking.
>
> The locking version would have to pretty much lock on a table
> basis (or even a whole-database basis) every time an assertion
> executed, no?
As far as I can see, if SSI is *not* used, there needs to be a
mutually exclusive lock taken from somewhere inside the COMMIT code
until the transaction is complete -- effectively serializing
assertion processing for transactions which could affect a given
assertion. Locking on tables would, as previously suggested, be
very prone to deadlocks on the heavyweight locks. Locking on the
assertions in a predictable order seems more promising, especially
if there could be some way to only do that if the transaction
really might have done something which could affect the truth of
the assertion.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-12-19 00:01:14 | Re: New option for pg_basebackup, to specify a different directory for pg_xlog |
Previous Message | Marko Tiikkaja | 2013-12-18 23:14:08 | Re: array_length(anyarray) |