From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Caune <daniel(dot)caune(at)ubisoft(dot)com>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE |
Date: | 2007-11-29 01:08:18 |
Message-ID: | 20071129010818.GA5118@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom Lane wrote:
> "Daniel Caune" <daniel(dot)caune(at)ubisoft(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Gera Mel Handumon | 2007-11-29 09:43:38 | Re: NULLIF problem |
Previous Message | Tom Lane | 2007-11-28 22:08:24 | Re: Strang behaviour SELECT ... LIMIT n FOR UPDATE |