Re: Update Query doesn't affect all records - Mailing list pgsql-general

From Alban Hertroys
Subject Re: Update Query doesn't affect all records
Date
Msg-id AF0B96CD-BB3B-401B-A947-1EB7FE16BB1B@solfertje.student.utwente.nl
Whole thread Raw
In response to Re: Update Query doesn't affect all records  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
On 5 Aug 2009, at 19:27, Scott Marlowe wrote:

> On Wed, Aug 5, 2009 at 6:56 AM, Csaba Nagy<nagy@ecircle-ag.com> wrote:
>> Hi Andor,
>>
>> On Wed, 2009-08-05 at 14:15 +0200, Schindler Andor wrote:
>>> Can anyone tell me, how this is possible? If we insert 12 on the
>>> end, then
>>> it decreases, but 11 remains the same. The problem only occurs,
>>> when the
>>> where condition contains "sorrend > 9" or less.
>>
>> I bet the "sorrend" column is of some text type, and the "sorrend >
>> 9"
>> comparison is a text comparison. Try "sorrend::integer > 9" and it
>> should work ;-)
>
> That's kinda what I was thinking at first, but the pastebin he posted
> showed them in proper int type order.  So I'm not sure why it's doing
> what it's doing.  I'd ask Schinlder if he could post a completely self


Besides, 10 does get decreased to 9. Not an integer cast to text case
apparently. Very strange...

The only thing I can think of is that the value '11' was inserted
after the update took place. The pastebin seems to indicate that all
these commands were executed in the same session though.

This isn't perchance some side-effect of a virus scanner interfering
with the database or some-such? Is this reproducible or is this a one-
time occurrence that you happened to catch?

Before you do anything to the database I suggest making a dump of this
database so that the evidence doesn't get lost if it gets fixed somehow.

You say adding a '12' record fixes the issue. Is the issue back if you
then delete that record again?

What happens if you run vacuum on that table? Does it report errors?
Does it fix the problem?

If you have an index on sorrend, reindexing it might fix your issue.
The interesting part is of course how it got in this state in the
first place... It almost looks like the index (provided there is one)
is giving inconsistent results. Or the xid on the row itself is doing
something strange (vacuum would probably have fixed that?).

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,4a7abcfd10131523526886!



pgsql-general by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: PG fails on Windows Server 2008: could not reattach to shared memory ... : 487
Next
From: Alvaro Herrera
Date:
Subject: Re: Sequence Not created with pg_dump