[
https://issues.apache.org/jira/browse/KUDU-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410218#comment-15410218
]
Adar Dembo commented on KUDU-500:
---------------------------------
bq. Maybe we should resolve this as 'Later' or 'wont fix' for now, since
although it might be a nice optimization some day, it's not on the roadmap.
Tempting, but I'd rather leave it open. This alternate design comes up every
now and then during discussions, and it's useful to be able to point to the
open bug report and to see it linked from KUDU-422.
Moreover, I don't think it's an undertaking of apocalyptic proportions. It's a
massive change to the catalog manager, but the only backward incompatibility
that I can think of is preventing clients from querying old follower masters
that don't implement this.
> Changes to SysTables should be queryable on follower leaders upon replication
> -----------------------------------------------------------------------------
>
> Key: KUDU-500
> URL: https://issues.apache.org/jira/browse/KUDU-500
> Project: Kudu
> Issue Type: Sub-task
> Components: master
> Affects Versions: M5
> Reporter: Alex Feinberg
>
> Currently CatalogManager serves requests from its in-memory objects. However,
> these objects are not updated on the replicas. There are two approaches for
> this: one is to serve CatalogManager from the underlying tablet (accepting
> potential latency hits, but making the implementation simpler), another is to
> implement callbacks on transaction completion on replicas (like MarkDirty but
> called whenever writes are committed on a replica).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
