Re: [PATCH] SQL assertions prototype - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: [PATCH] SQL assertions prototype
Date
Msg-id 52B0F362.6020907@agliodbs.com
Whole thread Raw
In response to [PATCH] SQL assertions prototype  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] SQL assertions prototype
Re: [PATCH] SQL assertions prototype
Re: [PATCH] SQL assertions prototype
List pgsql-hackers
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?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Extension Templates S03E11
Next
From: Maciek Sakrejda
Date:
Subject: [PATCH] Doc fix for VACUUM FREEZE