asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (ASTERIXDB-1952) Filters are not properly reconstructed during recovery
Date Wed, 28 Jun 2017 18:10:00 GMT


ASF subversion and git services commented on ASTERIXDB-1952:

Commit f86a25b8610cd11dab27a8ab5c8bc9f46afcea2c in asterixdb's branch refs/heads/master from
[;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

- 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
Integration-Tests: Jenkins <>
Tested-by: Jenkins <>
BAD: Jenkins <>
Reviewed-by: Murtadha Hubail <>

> Filters are not properly reconstructed during recovery
> ------------------------------------------------------
>                 Key: ASTERIXDB-1952
>                 URL:
>             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

View raw message