Re: [PATCH] SQL assertions prototype
От | Heikki Linnakangas |
---|---|
Тема | Re: [PATCH] SQL assertions prototype |
Дата | |
Msg-id | 52B18E10.7020000@vmware.com обсуждение исходный текст |
Ответ на | Re: [PATCH] SQL assertions prototype (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [PATCH] SQL assertions prototype
|
Список | 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
В списке pgsql-hackers по дате отправления: