Re: change in LOCK behavior
От | Simon Riggs |
---|---|
Тема | Re: change in LOCK behavior |
Дата | |
Msg-id | CA+U5nM+uftwXBoXXLr_d2-nuh6pgDJJg81U+fjLyyksHzL_eDQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: change in LOCK behavior (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 11 October 2012 19:41, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> On 11 October 2012 18:22, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> If it worked, I might be amenable to that, but it doesn't. You can't >>> trigger taking a new snapshot off whether we waited for a lock; that >>> still has race conditions, just ones that are not so trivial to >>> demonstrate manually. (The other transaction might have committed >>> microseconds before you reach the point of waiting for the lock.) > >> So where's the race? > > Same example as before, except that the exclusive-lock-holding > transaction commits (and releases its lock) between the time that the > other transaction takes its parse/plan snapshot and the time that it > takes AccessShare lock on the table. A cache invalidation could also set the need-second-snapshot flag. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: