[
https://issues.apache.org/jira/browse/ASTERIXDB-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066970#comment-16066970
]
ASF subversion and git services commented on ASTERIXDB-1952:
------------------------------------------------------------
Commit f86a25b8610cd11dab27a8ab5c8bc9f46afcea2c in asterixdb's branch
refs/heads/master from [~imaxon]
[ https://git-wip-us.apache.org/repos/asf?p=asterixdb.git;h=f86a25b ]
[ASTERIXDB-1952][TX][IDX]Log incoming filter vals
- user model changes: no
- interface changes: yes, for txn context
- storage format changes: yes, to log
details:
- Prior to this patch the filter values were not correct
on recovery. The tuple that was logged came from within
the wrapped indexand contained only the values to be stored.
In filtered scenarios this differs with what is fed to
the LSM wrapper to a respective index. redo plays the log
to the LSM wrapped index, so the input was simply not the
same on redo as it was during live ingestion. Three are other
ways to remedy this but the most straightforward is to simply
log what is given on input, and this is what this patch does.
- There is also a small fix for the way filters are accessed for
2ndary to primary search with an rtree index
Change-Id: I9268fe0b60145545c5933bab698d651c324397d7
Reviewed-on: https://asterix-gerrit.ics.uci.edu/1798
Integration-Tests: Jenkins <jenk...@fulliautomatix.ics.uci.edu>
Tested-by: Jenkins <jenk...@fulliautomatix.ics.uci.edu>
BAD: Jenkins <jenk...@fulliautomatix.ics.uci.edu>
Reviewed-by: Murtadha Hubail <hubail...@gmail.com>
> Filters are not properly reconstructed during recovery
> ------------------------------------------------------
>
> Key: ASTERIXDB-1952
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-1952
> Project: Apache AsterixDB
> Issue Type: Bug
> Reporter: Ian Maxon
> Assignee: Ian Maxon
>
> The redo process does not reconstruct the state of the in-memory component's
> filter right now. Basically it lacks the knowledge of either the metadata to
> extract this info, or the extra explicitly logged information. This causes
> the disk components created during recovery to have essentially bogus data
> for the filter values.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
