From: | Joe Wildish <joe-postgresql(dot)org(at)elusive(dot)cx> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implementing SQL ASSERTION |
Date: | 2018-01-15 21:14:02 |
Message-ID: | D5A3330B-4A60-488D-80C7-06BB9442DD67@elusive.cx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David,
> On 15 Jan 2018, at 16:35, David Fetter <david(at)fetter(dot)org> wrote:
>
> It sounds reasonable enough that I'd like to make a couple of Modest
> Proposals™, to wit:
>
> - We follow the SQL standard and make SERIALIZABLE the default
> transaction isolation level, and
>
> - We disallow writes at isolation levels other than SERIALIZABLE when
> any ASSERTION could be in play.
Certainly it would be easy to put a test into the assertion check function to require the isolation level be serialisable. I didn’t realise that that was also the default level as per the standard. That need not necessarily be changed, of course; it would be obvious to the user that it was a requirement as the creation of an assertion would fail without it, as would any subsequent attempts to modify the involved tables.
-Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2018-01-15 21:15:42 | Re: [HACKERS] WIP: Aggregation push-down |
Previous Message | Peter Geoghegan | 2018-01-15 20:33:12 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |