Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp columns not migrated to new format #6922

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

Timestamp columns not migrated to new format #6922

monetdb-team opened this issue Nov 30, 2020 · 0 comments
Labels
bug Something isn't working GDK Kernel major

Comments

@monetdb-team
Copy link

Date: 2020-07-09 18:34:10 +0200
From: jpastuszek
To: GDK devs <>
Version: 11.37.7 (Jun2020)

Last updated: 2020-07-27 09:30:15 +0200

Comment 27895

Date: 2020-07-09 18:34:10 +0200
From: jpastuszek

After migrating from Apr2019-SP1 to Jun2020, timestamp columns in data, that were already stored, are like -4652-01-22 instead of 2020-07-05. If I insert new data and query it, it all works fine. Looks like the data was not migrated correctly or at all.

After some digging in the code I found out that the migration only happens for the first BAT only - so only one BAT is ever migrated.

The reason for that is that the code is missing the handling of case where "ttype" is known after first BAT was migrated via "ATOMunknown_name" code path.

Patch:

--- a/gdk/gdk_bbp.c
+++ b/gdk/gdk_bbp.c
@@ -874,6 +877,11 @@ fixdatebats(void)
strcmp(anme, "daytime") == 0) &&
fixdateheap(b, anme) != GDK_SUCCEED)
return GDK_FAIL;

  •           } else if ((b->ttype == TYPE_date ||
    
  •                   b->ttype == TYPE_timestamp ||
    
  •                   b->ttype == TYPE_daytime) &&
    
  •                   fixdateheap(b, ATOMname(b->ttype)) != GDK_SUCCEED) {
    
  •                   return GDK_FAIL;
              }
      }
      return GDK_SUCCEED;
    

With this all BATs are processed and contain correct timestamps.

Comment 27897

Date: 2020-07-09 23:12:27 +0200
From: @sjoerdmullender

Good find!

I think that this is due to the moving of the time and date types into the GDK layer. In the previous release (Nov2019), TYPE_date etc. values weren't known in the GDK layer and these types were still really unknown to the GDK layer. So in the Nov2019 release, the code worked correctly (I'm pretty sure).
In the Jun2020 release, the date and time types were moved into the GDK layer, so they are no longer unknown at the point this code is run.
Since we officially don't support upgrades from older (more than one version ago) releases (we don't test it), we didn't notice. Having said that, if the upgrade can be made to work easily, we're happy to do it.
In other words, I'm happy with the fix. I'll adapt it a little and check it in.

Comment 27898

Date: 2020-07-09 23:29:49 +0200
From: MonetDB Mercurial Repository <>

Changeset 3ab4599c8f93 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

For complete details, see https//devmonetdborg/hg/MonetDB?cmd=changeset;node=3ab4599c8f93

Changeset description:

Fix for upgrade of time and date type columns since move of type to GDK.
This fixes bug #6922.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working GDK Kernel major
Projects
None yet
Development

No branches or pull requests

2 participants