From: | Martin Atukunda <matlads(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5784: CREATE INDEX USING GIN complains about array containing null values yet none exist |
Date: | 2010-12-05 19:06:21 |
Message-ID: | AANLkTimYnW6=wG+uf+UH1hEcGbde5M3DnMc2kzVkQ74b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sun, Dec 5, 2010 at 7:58 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On Sunday 05 December 2010 13:29:35 Andres Freund wrote:
> > On Sunday 05 December 2010 13:07:23 Martin Atukunda wrote:
> > > > Due to the wonders of MVCC the old row is still available in the
> heap.
> > > > Best read the docs about what MVCC means. And as pg's indexes don't
> > > > care about visibility it will still try to index the "old" row.
> > >
> > > Thanks andreas,
> > >
> > > so, basically, the only way out of this would be to:
> > >
> > > 1. copy out all the rows
> > > 2. truncate the Tables
> > > 3. then create the index
> > > 4. copy in the rows
> >
> > Something like:
> >
> > ALTER TABLE t ALTER apps TYPE text[];
> > ALTER TABLE t ALTER apps TYPE bigint[] USING apps::bigint[];
> On further thought the second one ought to be enough.
>
Actually on my tests here both are required, though for the large tables -
writing them twice makes the process very long. The copy out, truncate,
create index, copy in approach seems to work best in this case.
- Martin -
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2010-12-05 19:15:34 | Re: BUG #5783: plpythonu bool behavior change |
Previous Message | Tom Lane | 2010-12-05 17:26:45 | Re: BUG #5784: CREATE INDEX USING GIN complains about array containing null values yet none exist |