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
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 |