Daniel Caldeweyher writes:
> I had a similar issue once and was able to recover from it. If this affects
> only some rows and you are able to identify them, this is fixable:
> --force table scan to skip using corrupt index
> set enable_seqscan=1
> set enable_indexscan=0
> set
I had a similar issue once and was able to recover from it. If this affects
only some rows and you are able to identify them, this is fixable:
--force table scan to skip using corrupt index
set enable_seqscan=1
set enable_indexscan=0
set enable_bitmapscan=0
select email,count(*)
from users
group
On 9/2/16 8:02 AM, Adrian Klaver wrote:
Best guess is the INDEX on the column is corrupted and needs to be
reindexed:
You should contact AWS support about this; they'd want to know.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and
Jonas Tehler wrote:
> We’re running Postgresql 9.4.5 on Amazon RDS. One of our tables looks
> something like this:
>
>
> CREATE TABLE users
> (
> ...
> email character varying(128) NOT NULL,
> ...
> CONSTRAINT users_email_key UNIQUE (email)
> )
>
> Despite this we have rows with very
On 09/02/2016 04:32 AM, Jonas Tehler wrote:
Hi,
We’re running Postgresql 9.4.5 on Amazon RDS. One of our tables
looks something like this:
CREATE TABLE users
(
...
email character varying(128) NOT NULL,
...
CONSTRAINT users_email_key UNIQUE (email)
)
Despite this we have rows with
Hi,
We’re running Postgresql 9.4.5 on Amazon RDS. One of our tables looks something
like this:
CREATE TABLE users
(
...
email character varying(128) NOT NULL,
...
CONSTRAINT users_email_key UNIQUE (email)
)
Despite this we have rows with very similar email values. I discovered the