Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE
От | Alvaro Herrera |
---|---|
Тема | Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE |
Дата | |
Msg-id | 20071129010818.GA5118@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-sql |
Tom Lane wrote: > "Daniel Caune" <daniel.caune@ubisoft.com> writes: > > It seems that, in certain condition, row (199,84) is shadowing row > > (3702,85); > > This would be the expected behavior if row (199,84) were an updated > version of row (3702,85), but you couldn't see it yet in your current > transaction snapshot. A plain SELECT would show the older version > (the current one according to the snapshot) while SELECT FOR UPDATE > would show the newest committed version. Hmm. We've been studying a case on one customer where xmin/xmax seem to be corrupted. It has had ups and downs because I have my doubts about their storage system, but I'm not completely sure that it can be really blamed. This is on 8.1.10. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4" Major Fambrough: You wish to see the frontier? John Dunbar: Yes sir, before it's gone.
В списке pgsql-sql по дате отправления: