Re: ALTER TABLE lock strength reduction patch is unsafe
От | Tom Lane |
---|---|
Тема | Re: ALTER TABLE lock strength reduction patch is unsafe |
Дата | |
Msg-id | 27994.1325531580@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE lock strength reduction patch is unsafe (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: ALTER TABLE lock strength reduction patch is unsafe
Re: ALTER TABLE lock strength reduction patch is unsafe |
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > On Mon, Jan 2, 2012 at 6:06 PM, Noah Misch <noah@leadboat.com> wrote: >> On Mon, Jan 02, 2012 at 05:09:16PM +0000, Simon Riggs wrote: >>> Attached patch makes SnapshotNow into an MVCC snapshot, >> That's a neat trick. �However, if you start a new SnapshotNow scan while one is >> ongoing, the primordial scan's snapshot will change mid-stream. > Do we ever do that? Almost certainly yes. For example, a catcache load may invoke catcache or relcache reload operations on its way to opening the table or index needed to fetch the desired row. I think you can only safely do this if each caller has its own snapshot variable, a la SnapshotDirty, and that's going to be hugely more invasive. regards, tom lane
В списке pgsql-hackers по дате отправления: