Support Npgsql 6.0 for clustering and reminders - #7402
Merged
Merged
Conversation
Member
|
LGTM. Thank you, @EdeMeijer! |
Contributor
Author
|
I forgot to mention, I only tested this with a Cockroach DB backend, not actual postgres. I'm 99,99% sure it will be all the same though. |
ReubenBond
added
the
Needs: backport
ReubenBond
added a commit
that referenced
this pull request
Jan 12, 2022
* Create PostgreSQL migrations for version 3.6.0 The changes in #7402 are fine for new deployments, but existing deployments need a way to migrate tables and routines in order to apply the same changes. Users can run the SQL in the 3 migration files when upgrading to 3.6.0 Co-authored-by: Reuben Bond <203839+ReubenBond@users.noreply.github.com>
ReubenBond
added a commit
to ReubenBond/orleans
that referenced
this pull request
Jan 12, 2022
* Create PostgreSQL migrations for version 3.6.0 The changes in dotnet#7402 are fine for new deployments, but existing deployments need a way to migrate tables and routines in order to apply the same changes. Users can run the SQL in the 3 migration files when upgrading to 3.6.0 Co-authored-by: Reuben Bond <203839+ReubenBond@users.noreply.github.com>
ReubenBond
added a commit
that referenced
this pull request
Jan 12, 2022
* Create PostgreSQL migrations for version 3.6.0 The changes in #7402 are fine for new deployments, but existing deployments need a way to migrate tables and routines in order to apply the same changes. Users can run the SQL in the 3 migration files when upgrading to 3.6.0 Co-authored-by: Reuben Bond <203839+ReubenBond@users.noreply.github.com> Co-authored-by: Ede Meijer <ede@elastict.nl>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Starting with Npgsql 6.0, date-time handling got more strict (https://www.npgsql.org/doc/types/datetime.html#timestamps-and-timezones). Using Npgsql 6.0 with Orleans broke some clustering queries, in particular when trying to mark previous versions of the same silo as dead when the previous version did not shutdown gracefully.
The issue is that when loading current cluster members, the DateTimes were loaded with type
unspecified, because the table usesdatetime without time zone. Then when reusing those date objects for update queries, Npgsql would not allow this anymore.My solution is to follow the general advice for Postgres to always use
timestamp with time zone(timestamptz) for storing date-times. By doing so, the membership DateTime gets loaded with typeutc, and everything keeps working.For consistency I also updated the date columns for reminders, and verified everything still works.
Microsoft Reviewers: Open in CodeFlow