From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] SQL assertions prototype |
Date: | 2013-12-18 11:59:12 |
Message-ID: | 52B18E10.7020000@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2013-12-18 12:02:05 | Re: PoC: Partial sort |
Previous Message | Alexander Korotkov | 2013-12-18 11:53:06 | Re: PoC: Partial sort |