Re: [CORE] FOR SHARE vs FOR UPDATE locks
От | Tom Lane |
---|---|
Тема | Re: [CORE] FOR SHARE vs FOR UPDATE locks |
Дата | |
Msg-id | 1582.1165001233@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [CORE] FOR SHARE vs FOR UPDATE locks (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > Josh Berkus wrote: >> So, I think it needs to go on the list for 8.2.1 or 8.3 (depending on what >> changes the fix requires) but I don't think we should hold up the release. > We cannot add something this major in a minor release --- it would have > to be 8.3. If someone thinks of a brilliant solution that doesn't change on-disk layout, maybe we could implement it in 8.2.x, but right now I'm not feeling hopeful about that. The best idea I have at the moment is that we might be able to do something as part of the proposed plan to fold cmin/cmax into a single field. The thought there was that there could be some in-memory state for tuples that had been modified multiple times by a single xact --- perhaps that could be extended to cover this problem. This is just handwaving at the moment though. In particular, is-the-tuple-locked-or-not seems like it has to be externally visible state, so maybe it can't work. regards, tom lane
В списке pgsql-hackers по дате отправления: