On Tue, Dec 10, 2013 at 11:00 PM, Mason Sharp <msharp@translattice.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
