Skip to content
Snippets Groups Projects
  1. Oct 28, 2021
  2. Oct 27, 2021
    • Nicolas Dandrimont's avatar
      grab_next_visits: avoid time interval calculations in PostgreSQL · 0c7ef27b
      Nicolas Dandrimont authored
      When the database is in a non-UTC timezone with DST, and a `timestamptz
      - interval` calculation crosses a DST change, the result of the
      calculation can be one hour off from the expected value:
      
      PostgreSQL will vary the timestamp by the amount of days in the
      interval, and will keep the same (local) time, which will be offset by
      an hour because of the DST change.
      
      Doing the datetime +- timedelta calculations in Python instead of
      PostgreSQL avoids this caveat altogether.
      0c7ef27b
  3. Oct 22, 2021
  4. Oct 20, 2021
  5. Oct 18, 2021
  6. Oct 15, 2021
  7. Sep 02, 2021
  8. Aug 27, 2021
  9. Aug 26, 2021
  10. Aug 18, 2021
  11. Aug 06, 2021
  12. Aug 03, 2021
  13. Jul 30, 2021
  14. Jul 23, 2021
    • Nicolas Dandrimont's avatar
      Only record last_visited and last_successful in origin_visit_stats · 87e66faa
      Nicolas Dandrimont authored
      After using this schema for a while, all queries can be implemented in
      terms of these two timestamps, instead of the four original
      last_eventful, last_uneventful, last_failed and last_notfound
      timestamps.
      
      This ends up simplifying the logic within the journal client, as well as
      that of the grab_next_visits query builder.
      
      To make this change work, we also stop considering out of order messages
      altogether in journal_client. This welcome simplification is an accuracy
      tradeoff that is explained in the updated documentation of the journal
      client:
      
      .. [1] Ignoring out of order messages makes the initialization of the
            origin_visit_status table (from a full journal) less deterministic: only the
            `last_visit`, `last_visit_state` and `last_successful` fields are guaranteed
            to be exact, the `next_position_offset` field is a best effort estimate
            (which should converge once the client has run for a while on in-order
            messages).
      87e66faa
    • Antoine R. Dumont's avatar
      test_journal_client: Unify test assertion like the rest · 3ca0d659
      Antoine R. Dumont authored
      Related to D5917
      3ca0d659
Loading