On 12/18/2013 02:59 AM, Josh Berkus wrote:
> On 12/17/2013 01:42 PM, Kevin Grittner wrote:
>> Josh Berkus <josh@agliodbs.com> wrote:
>>> Going back over this patch, I haven't seen any further discussion of the
>>> point Heikki raises above, which seems like a bit of a showstopper.
>>>
>>> Heikki, did you have specific ideas on how to solve this? Right now my
>>> mind boggles.
>>
>> It works fine as long as you set default_transaction_isolation =
>> 'serializable' and never override that. :-) Of course, it sure
>> would be nice to have a way to prohibit overrides, but that's
>> another issue.
>>
>> Otherwise it is hard to see how to make it work in a general way
>> without a mutually exclusive lock mode on the table for the
>> duration of any transaction which modifies the table.
>
> Serializable or not, *what* do we lock for assertions? It's not rows.
> Tables? Which tables? What if the assertion is an interpreted language
> function? Does the SSI reference counter really take care of all of this?
SSI does make everything rosy, as long as all the transactions
participate in it. The open questions revolve around what happens if a
transaction is not running in SSI mode.
If you force everyone to run in SSI as soon as you create even a single
assertion in your database, that's kind of crappy for performance. Also,
if one user creates an assertion, it becomes a funny kind of a partial
denial of service attack to other users, if you force other user's to
also run in SSI mode.
If you don't force everything to run in SSI mode, then you have to
somehow figure out what parts do need to run in SSI mode to enforce the
assertion. For example, if the assertion refers tables A and B, perhaps
you can get away without predicate locks on table C?
- Heikki