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:46:59
Message-ID: 52B18B33.1030702@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. Now, there's a race condition, if another transaction is
>> committing at the same time, and performs the same check concurrently. That
>> race condition can be eliminated by holding an exclusive lock while running
>> the assertion, until commit, effectively allowing the assertion to be
>> checked by only one transaction at a time.
>>
>> 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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2013-12-18 11:48:17 Re: hstore ng index for <@ ?
Previous Message Alexander Korotkov 2013-12-18 11:45:00 Re: GIN improvements part 1: additional information