RE: Possible corrupt index?

From: Zahir Lalani <ZahirLalani(at)oliver(dot)agency>
To: Michael Lewis <mlewis(at)entrata(dot)com>
Cc: "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: RE: Possible corrupt index?
Date: 2019-04-16 17:16:02
Message-ID: AM0PR06MB40042CE1B471960D6091962CA7240@AM0PR06MB4004.eurprd06.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


>Which version? What are the queries you are running which give unexpected behavior? Have your run explain analyze on those to check >what plan is being used? Have your reindexed all or only the one you suspect?

Hi Michael

Version: PostgreSQL 9.6.12 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36), 64-bit

LIVE – production environment (as opposed to Dev and UAT)

Query: select id from briefs_master where ext_system_ref = '12345'

Explain:
Seq Scan on briefs_master (cost=0.00..2937.90 rows=1 width=4) (actual time=18.082..18.082 rows=0 loops=1)
Filter: ((ext_system_ref)::text = '12345'::text)
Rows Removed by Filter: 31235
Planning time: 0.242 ms
Execution time: 18.096 ms

Reindex was done initially on the primary and then on all in the table.

So when we reset the data into the ext_system_ref field, the next query returns fine. However, the issue is that since the system thinks there is no primary, we are seeing this value get over-written with a null several minutes later as other rows are added

Z

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2019-04-16 17:23:29 Re: Possible corrupt index?
Previous Message Adrian Klaver 2019-04-16 17:08:04 Re: Possible corrupt index?