Thread: BUG #13324: Database returing incorrect results on querying slect clause

The following bug has been logged on the website:

Bug reference:      13324
Logged by:          Krishna Sharma
Email address:      ksharma6@metlife.com
PostgreSQL version: Unsupported/Unknown
Operating system:   Windows 2003
Description:

Hi PostgreSQL team, we are suing PostGreSQL 8.2.

When I run a query in database like
select * from dn_case where id= 1234.

it returns 2 rows with different ids.

How is this happening?

it seems the database is corrupt. Please suggest a soluton for this issue.

On Thu, May 21, 2015 at 12:23 PM, <ksharma6@metlife.com> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      13324
> Logged by:          Krishna Sharma
> Email address:      ksharma6@metlife.com
> PostgreSQL version: Unsupported/Unknown
> Operating system:   Windows 2003
> Description:
>
> Hi PostgreSQL team, we are suing PostGreSQL 8.2.
>
> When I run a query in database like
> select * from dn_case where id= 1234.
>
> it returns 2 rows with different ids.
>
> How is this happening?
>
> it seems the database is corrupt. Please suggest a soluton for this issue.
>

It seems to be. Cannot be confirmed without much details. Can you please
share the output ? is this reproducible ?

Also, can you let us know some details on what exactly was happening in the
database.

Regards,
Venkata B N

Fujitsu Australia

On Thu, May 21, 2015 at 2:23 PM,  <ksharma6@metlife.com> wrote:
> The following bug has been logged on the website:
>
> Bug reference:      13324
> Logged by:          Krishna Sharma
> Email address:      ksharma6@metlife.com
> PostgreSQL version: Unsupported/Unknown
> Operating system:   Windows 2003
> Description:
>
> Hi PostgreSQL team, we are suing PostGreSQL 8.2.
>
> When I run a query in database like
> select * from dn_case where id= 1234.
>
> it returns 2 rows with different ids.
>
> How is this happening?

With no other information, my first guess would be that an index has
somehow become corrupted.

> it seems the database is corrupt. Please suggest a soluton for this issue.

The solution may be to rebuild the index:

http://www.postgresql.org/docs/8.2/static/sql-reindex.html

(That is a very old PostgreSQL release which is no longer supported
because it reached 'EOL' status in 2011:
http://www.postgresql.org/support/versioning/ ).

--
Thomas Munro
http://www.enterprisedb.com

On Thu, May 21, 2015 at 3:23 AM,  <ksharma6@metlife.com> wrote:
> Hi PostgreSQL team, we are suing PostGreSQL 8.2.


The bad news is that Postgres 8.2 is very very old. It's been over
three years since we stopped updating or supporting that version. It's
possible you've hit one of the known bugs fixed in point releases (the
last was 8.2.23) or it's possible you've found a new bug. But it's
unlikely anyone is going to be digging out 8.2 sources to debug it
unless you're interested in hiring someone to do so.

It's possible that running REINDEX will fix your database for now but
I would strongly suggest using pg_dump to dump your database and then
restore it into a Postgres 9.4 database.

--
greg

VGhhbmtzLA0KDQpZZXMgd2UgYWxzbyB0aGluayB0aGUgc2FtZSB0aGF0IGluZGV4IGFyZSBjb3Jy
dXB0Lg0KDQpJcyB0aGVyZSBhIHdheSB0byBmaW5kIGFsbCB0aGUgY29ycnVwdCBpbmRleGVzPw0K
DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgQ09ORklE
RU5USUFMIGFuZCBpcyBmb3IgdGhlIGludGVuZGVkIGFkZHJlc3NlZSBvbmx5LiAgQW55IHVuYXV0
aG9yaXplZCB1c2UsIGRpc3NlbWluYXRpb24gb2YgdGhlIGluZm9ybWF0aW9uLCBvciBjb3B5aW5n
IG9mIHRoaXMgbWVzc2FnZSBpcyBwcm9oaWJpdGVkLiAgSWYgeW91IGFyZSBub3QgdGhlIGludGVu
ZGVkIGFkZHJlc3NlZSwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk
ZWxldGUgdGhpcyBtZXNzYWdlLgo=

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only.  Any unauthorized use, dissemination of the information, or copying of this message is prohibited.  If you are not the intended addressee, please notify the sender immediately and delete this message.

On Fri, May 22, 2015 at 10:20 AM, Sharma, Krishna Kumar <
ksharma6@metlife.com> wrote:

> Thanks,
>
> Yes we also think the same that index are corrupt.
>
> Is there a way to find all the corrupt indexes?
>

AFAIK there is no straight forward way to identify the corrupted Indexes.

Regards,
Venkata Balaji N

Fujitsu Australia

VGhhbmtzLg0KDQpXZSBkaWQgcmUtaW5kZXggYW5kIHRoYXQgZml4ZWQgdGhlIGlzc3VlLg0KDQpZ
b3UgY2FuIGNsb3NlIHRoZSBjYXNlLg0KDQoNCg0KRnJvbTogVmVua2F0YSBCYWxhamkgTiBbbWFp
bHRvOm5hZzEwMTBAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXksIE1heSAyMywgMjAxNSA1OjEy
IEFNDQpUbzogU2hhcm1hLCBLcmlzaG5hIEt1bWFyDQpDYzogVGhvbWFzIE11bnJvOyBQb3N0Z3Jl
U1FMIEJ1Z3MNClN1YmplY3Q6IFJlOiBbQlVHU10gQlVHICMxMzMyNDogRGF0YWJhc2UgcmV0dXJp
bmcgaW5jb3JyZWN0IHJlc3VsdHMgb24gcXVlcnlpbmcgc2xlY3QgY2xhdXNlDQoNCk9uIEZyaSwg
TWF5IDIyLCAyMDE1IGF0IDEwOjIwIEFNLCBTaGFybWEsIEtyaXNobmEgS3VtYXIgPGtzaGFybWE2
QG1ldGxpZmUuY29tPG1haWx0bzprc2hhcm1hNkBtZXRsaWZlLmNvbT4+IHdyb3RlOg0KVGhhbmtz
LA0KDQpZZXMgd2UgYWxzbyB0aGluayB0aGUgc2FtZSB0aGF0IGluZGV4IGFyZSBjb3JydXB0Lg0K
DQpJcyB0aGVyZSBhIHdheSB0byBmaW5kIGFsbCB0aGUgY29ycnVwdCBpbmRleGVzPw0KDQpBRkFJ
SyB0aGVyZSBpcyBubyBzdHJhaWdodCBmb3J3YXJkIHdheSB0byBpZGVudGlmeSB0aGUgY29ycnVw
dGVkIEluZGV4ZXMuDQoNClJlZ2FyZHMsDQpWZW5rYXRhIEJhbGFqaSBODQoNCkZ1aml0c3UgQXVz
dHJhbGlhDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBi
ZSBDT05GSURFTlRJQUwgYW5kIGlzIGZvciB0aGUgaW50ZW5kZWQgYWRkcmVzc2VlIG9ubHkuICBB
bnkgdW5hdXRob3JpemVkIHVzZSwgZGlzc2VtaW5hdGlvbiBvZiB0aGUgaW5mb3JtYXRpb24sIG9y
IGNvcHlpbmcgb2YgdGhpcyBtZXNzYWdlIGlzIHByb2hpYml0ZWQuICBJZiB5b3UgYXJlIG5vdCB0
aGUgaW50ZW5kZWQgYWRkcmVzc2VlLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl
bHkgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UuCg==