Re: [PATCH] SQL assertions prototype
От | Josh Berkus |
---|---|
Тема | Re: [PATCH] SQL assertions prototype |
Дата | |
Msg-id | 52B0F362.6020907@agliodbs.com обсуждение исходный текст |
Ответ на | [PATCH] SQL assertions prototype (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: [PATCH] SQL assertions prototype
Re: [PATCH] SQL assertions prototype Re: [PATCH] SQL assertions prototype |
Список | pgsql-hackers |
On 12/17/2013 01:42 PM, Kevin Grittner wrote: > Josh Berkus <josh@agliodbs.com> wrote: >> Going back over this patch, I haven't seen any further discussion of the >> point Heikki raises above, which seems like a bit of a showstopper. >> >> Heikki, did you have specific ideas on how to solve this? Right now my >> mind boggles. > > It works fine as long as you set default_transaction_isolation = > 'serializable' and never override that. :-) Of course, it sure > would be nice to have a way to prohibit overrides, but that's > another issue. > > Otherwise it is hard to see how to make it work in a general way > without a mutually exclusive lock mode on the table for the > duration of any transaction which modifies the table. Serializable or not, *what* do we lock for assertions? It's not rows. Tables? Which tables? What if the assertion is an interpreted language function? Does the SSI reference counter really take care of all of this? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: