Re: assertions and constraint triggers - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: assertions and constraint triggers
Date
Msg-id 4C626CFF02000025000344C0@gw.wicourts.gov
Whole thread Raw
In response to Re: assertions and constraint triggers  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
List pgsql-hackers
Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi> wrote:
> On 8/11/10 1:18 PM +0300, Peter Eisentraut wrote:
>> On ons, 2010-08-11 at 10:54 +0300, Marko Tiikkaja wrote:
>>> Enforcing that kind of constraints without true serializability
>>> seems impractical.
>>
>> Yes, but that is being worked on, I understand.
> 
> Correct.  But you'd have to somehow make the constraints to be
> checked with true serializability, and that part of the original
> suggestion seemed to be completely missing.  Not sure how hard
> that would be though.
I keep bumping into use cases where cool things could be done if you
could be sure that *all* transactions were being run at the fully
serializable transaction isolation level.  Perhaps we could look at
a GUC (or initdb option, if people fear the consequences of changes
in an existing database) which not only defaults to serializable,
but silently ignores requests for other levels.  If we only allowed
these constraints to be used in a database which was configured this
way, they would work fine.
Enforcing *part* of a transaction under full serializable isolation
seems totally infeasible, unless someone has a clever idea I'm
missing.
-Kevin


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [ADMIN] postgres 9.0 crash when bringing up hot standby
Next
From: Tom Lane
Date:
Subject: Re: string_to_array with an empty input string