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

From: Koichi Suzuki <koichi(dot)dbms(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Mason Sharp <msharp(at)translattice(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 03:50:10
Message-ID: CABEZHFs40uc-MCES2hQMpDi4-d7RErXboAT-Yfd_xgGMDHjxVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In 1.0, we added new APIs to GTM so that vacuum can run with global
XID and snapshot. We may need more improvement to use this.

It is wonderful if Mason provides a patch to fix this.

Regards;
---
Koichi Suzuki

2013/12/11 Michael Paquier <michael(dot)paquier(at)gmail(dot)com>:
> On Tue, Dec 10, 2013 at 11:00 PM, Mason Sharp <msharp(at)translattice(dot)com> wrote:
>> In our StormDB fork (now TransLattice Storm) I made some changes to address
>> some issues that were uncovered with XC. I am not sure if it will address
>> this specific issue above, but in most cases we make it an error instead of
>> falling back to a local XID like XC does (imagine if a node cannot reach GTM
>> and autovacuum starts cleaning up data with local XIDs and snapshots) .
> Yep, falling back to a local xid when GTM is not reachable has been
> done since the beginning of the project. Considering that as a bug
> using the argument that it endangers data visibility, such a patch
> should be back-patched as well. Some insight on those remarks from the
> core team would be welcome though.
>
>> Also, we use GTM for getting XIDs for authentication and for autovacuum
>> launcher because in concurrency testing not doing so results in the same XID
>> being consumed by other sessions and causing hanging and other transaction
>> problems. The bottom line is falling back to local XIDs and snapshots should
>> almost always be avoided (initdb is ok).
> Check.
>
>> Our code is a bit different from vanilla XC, but I can try to put together a
>> similar patch soon.
> This would be welcome.
>
>> As a community I feel we should prioritize more on testing and bug fixing
>> like the reported issue and replicated table handling than on new features
>> like the merged coordinator and datanode project.
> Definitely, *normal* developers cannot afford spending so much time on
> projects as big as that. One of the big things that I see missing is a
> public instance of an XC buildfarm, by using for example the buildfarm
> code of Postgres that simply fetches the code from git, and kicks
> in-core tests. For XC this should be restricted though to regressions,
> and compilation. pg_upgrade or isolation tests are not really
> working...
>
> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sameer Kumar 2013-12-11 04:02:23 Trigger Firing Order
Previous Message Michael Paquier 2013-12-11 03:22:57 Re: [Postgres-xc-general] "Tuple not found error" during Index creation