Re: Update Query doesn't affect all records

From: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Schindler Andor <schindler(dot)andor(at)pokhalo(dot)hu>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Update Query doesn't affect all records
Date: 2009-08-06 11:22:28
Message-ID: AF0B96CD-BB3B-401B-A947-1EB7FE16BB1B@solfertje.student.utwente.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5 Aug 2009, at 19:27, Scott Marlowe wrote:

> On Wed, Aug 5, 2009 at 6:56 AM, Csaba Nagy<nagy(at)ecircle-ag(dot)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!

In response to

Browse pgsql-general by date

  From Date Subject
Next Message sub_woofer 2009-08-06 12:42:05 Postgresql Backups
Previous Message Magnus Hagander 2009-08-06 11:00:54 Re: PG fails on Windows Server 2008: could not reattach to shared memory ... : 487