Re: assertions and constraint triggers

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: assertions and constraint triggers
Дата
Msg-id 4C626CFF02000025000344C0@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: assertions and constraint triggers  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [ADMIN] postgres 9.0 crash when bringing up hot standby
Следующее
От: Tom Lane
Дата:
Сообщение: Re: string_to_array with an empty input string