From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Sandeep Gupta <gupta(dot)sandeep(at)gmail(dot)com> |
Cc: | John R Pierce <pierce(at)hogranch(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> |
Subject: | Re: [Postgres-xc-general] "Tuple not found error" during Index creation |
Date: | 2013-12-10 01:49:31 |
Message-ID: | CAB7nPqT1q=hbL9+B-GVMwbpkmXaZw2e-onYrST6PUyBXzDN67w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Dec 10, 2013 at 7:17 AM, Sandeep Gupta <gupta(dot)sandeep(at)gmail(dot)com> wrote:
> We are trying to trace cause and potential solution of "tuple not found"
> error with postgres-xc. The problem happens when indexing a large file. It
> seems the autovaccum locks certain cache pages that the indexer tries to
> read. The indexing fails with "tuple not found" error.
>
> I am sure if it qualifies as postgres or postgres-xc error. However, I was
> just wondering what is the recommended way to go about fixing this. Turning
> off the autovaccumer is really not the best of solution because then the
> system runs into memory usage error.
>
> Would greatly appreciate any pointers on this.
This smells like a concurrency issue with autovacuum on XC side. I
recall fixing in the past issues with autovacuum not taking a correct
snapshot from GTM in certain code paths, putting in danger data
consistency in the cluster as autovacuum might clean more tuples than
it should. Another possibility to explain this bug would be the way
RecentGlobalXmin is computed for autovacuum using the GTM snapshots,
which would explain why autovacuum has cleaned away some tuples it
should not have, making the possibility of a failure higher for
long-running transactions.
Those are assumptions though. It would be great if you could provide a
self-contained test case, with let's imagine a table that has its data
generated with for example generate_series. Just by seeing the spec of
the machine you are using, I am sure that i wouldn't be able to
reproduce that on my laptop though. The core team has access to more
powerful machines.
Also: Postgres-XC 1.1.0 is based on Postgres 9.2.4.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2013-12-10 01:59:45 | Re: Replication: GZIP compression in WAL sender/receiver processes communication? |
Previous Message | Dmitry Koterov | 2013-12-09 23:13:17 | Replication: GZIP compression in WAL sender/receiver processes communication? |