Re: [Postgres-xc-general] "Tuple not found error" during Index creation

From: Mason Sharp <msharp(at)translattice(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Sandeep Gupta <gupta(dot)sandeep(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, "<postgres-xc-general(at)lists(dot)sourceforge(dot)net>" <postgres-xc-general(at)lists(dot)sourceforge(dot)net>, John R Pierce <pierce(at)hogranch(dot)com>
Subject: Re: [Postgres-xc-general] "Tuple not found error" during Index creation
Date: 2013-12-11 16:55:30
Message-ID: CA+A7BJF1-u9ZJjn9GUCAnpeb8xq-XLJKW5QLR+kX0M2x1=N_9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Dec 10, 2013 at 11:23 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com
> wrote:

> On Wed, Dec 11, 2013 at 1:17 PM, Sandeep Gupta <gupta(dot)sandeep(at)gmail(dot)com>
> wrote:
> > Hi Michael,
> >
> > I can provide the table schema and the data over which indexing almost
> > always fails with tuple not found error.
> > Would this be of help. The other issue is that file is 3.2GB so we
> would
> > have work some logistics to transfer this across.
> Transferring a data file of a couple of gigs is out of question. My
> point was to know if you are able to create a self-contained test case
> using automatically generated data of this type:
> create table foo as select generate_series(1,100000000) as a, 'bbbb'::text
> as b;
> create index fooi on aa(a);
> Or smth like that.
> This way you wouldn't need to 1) publish your schema, 2) transfer huge
> files of data. And this would make tracking of this error somewhat
> easier.
>

Perhaps I could help Sandeep. Sandeep, before working out transferring such
a large file though, please instead try to pinpoint the particular commit
that introduced the issue.

I could recently reproduce a problem with VACUUM FULL in XC 1.1 (stop
cluster, restart cluster, execute VACUUM FULL). I could not reproduce the
problem however with a build from the
commit 11339220012a9e73cb82039b0ad41afd71bafca2 on Aug 22, 2012. I suspect
that a commit after that one to procarray.c may have something to do with
the problem. It may be a similar issue for you. If you have the time,
perhaps you can try different commits based on the git log of procarray.c
to see if any particular one introduced the issue.

I would use the commit not just on procarray, but on the entire source
tree. If you find a suspect one based on procarray.c, try the one
immediately preceding it for the whole source tree to confirm that it is
procarray-related.

Again, this all may be unrelated, but I think it is a good place to start,
so I apologize in advance if this chews up some of your time unnecessarily.

> Regards,
> --
> Michael
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Postgres-xc-general mailing list
> Postgres-xc-general(at)lists(dot)sourceforge(dot)net
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>

--
Mason Sharp

TransLattice - http://www.translattice.com
Distributed and Clustered Database Solutions

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message salah jubeh 2013-12-11 16:59:10 Re: Convert table to view 9.1
Previous Message Jeff Janes 2013-12-11 16:54:05 Re: Question about optimizing access to a table.