On 12/18/2013 01:50 PM, Andres Freund wrote:
> On 2013-12-18 13:46:59 +0200, Heikki Linnakangas wrote:
>> On 12/18/2013 01:39 PM, Andres Freund wrote:
>>> On 2013-12-18 13:07:51 +0200, Heikki Linnakangas wrote:
>>>> Here's another idea that doesn't involve SSI:
>>>>
>>>> At COMMIT, take a new snapshot and check that the assertion still passes
>>>> with that snapshot.
>>>> I think that would work, and would be simple, although it wouldn't scale too
>>>> well.
>>>
>>> It probably would also be very prone to deadlocks.
>>
>> Hmm, since this would happen at commit, you would know all the assertions
>> that need to be checked at that point. You could check them e.g in Oid order
>> to avoid deadlocks.
>
> I think real problem are the lock upgrades, because eventual DML will
> have acquired less heavy locks.
Ah, I see. You don't need to block anyone else from modifying the table,
you just need to block anyone else from committing a transaction that
had modified the table. So the locks shouldn't interfere with regular
table locks. A ShareUpdateExclusiveLock on the assertion should do it.
- Heikki