Re: [PATCH] SQL assertions prototype

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

In response to

Responses

Browse pgsql-hackers by date

  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