Re: ALTER TABLE lock strength reduction patch is unsafe
От | Simon Riggs |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | CA+U5nM+za1mX5kTy-y+iUf1Acir4w70kHbBeedJ2iijpE5mJvg@mail.gmail.com обсуждение исходный текст |
Ответ на | ALTER TABLE lock strength reduction patch is unsafe (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
Re: ALTER TABLE lock strength reduction patch is unsafe |
Список | pgsql-hackers |
On 3 January 2012 18:42, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >>> Another point that requires some thought is that switching SnapshotNow >>> to be MVCC-based will presumably result in a noticeable increase in each >>> backend's rate of wanting to acquire snapshots. > > BTW, I wonder if this couldn't be ameliorated by establishing some > ground rules about how up-to-date a snapshot really needs to be. > Arguably, it should be okay for successive SnapshotNow scans to use the > same snapshot as long as we have not acquired a new lock in between. > If not, reusing an old snap doesn't introduce any race condition that > wasn't there already. Now that has been implemented using the above design, we can resubmit the lock level reduction patch, with thanks to Robert. Submitted patch passes original complaint/benchmark. Changes * various forms of ALTER TABLE, notably ADD constraint and VALIDATE * CREATE TRIGGER One minor coirrections to earlier thinking with respect to toast tables. That might be later relaxed. Full tests including proof of lock level reductions, plus docs. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: