-
Notifications
You must be signed in to change notification settings - Fork 68
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
Bump default version; add upgrade script #72
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,62 @@ | ||
CREATE FUNCTION partition_column_to_node_string(table_oid oid) | ||
RETURNS text | ||
AS 'MODULE_PATHNAME' | ||
LANGUAGE C; | ||
|
||
COMMENT ON FUNCTION partition_column_to_node_string(oid) | ||
IS 'return textual form of distributed table''s partition column'; | ||
|
||
CREATE FUNCTION sync_table_metadata_to_citus(table_name text) RETURNS VOID | ||
AS $sync_table_metadata_to_citus$ | ||
DECLARE | ||
table_relation_id CONSTANT oid NOT NULL := table_name::regclass::oid; | ||
dummy_shard_length CONSTANT bigint := 0; | ||
BEGIN | ||
-- copy shard placement metadata | ||
INSERT INTO pg_dist_shard_placement | ||
(shardid, | ||
shardstate, | ||
shardlength, | ||
nodename, | ||
nodeport) | ||
SELECT shard_id, | ||
shard_state, | ||
dummy_shard_length, | ||
node_name, | ||
node_port | ||
FROM pgs_distribution_metadata.shard_placement | ||
WHERE shard_id IN (SELECT id | ||
FROM pgs_distribution_metadata.shard | ||
WHERE relation_id = table_relation_id); | ||
|
||
-- copy shard metadata | ||
INSERT INTO pg_dist_shard | ||
(shardid, | ||
logicalrelid, | ||
shardstorage, | ||
shardminvalue, | ||
shardmaxvalue) | ||
SELECT id, | ||
relation_id, | ||
storage, | ||
min_value, | ||
max_value | ||
FROM pgs_distribution_metadata.shard | ||
WHERE relation_id = table_relation_id; | ||
|
||
-- copy partition metadata, which also converts the partition column to | ||
-- a node string representation as expected by CitusDB | ||
INSERT INTO pg_dist_partition | ||
(logicalrelid, | ||
partmethod, | ||
partkey) | ||
SELECT relation_id, | ||
partition_method, | ||
partition_column_to_node_string(table_relation_id) | ||
FROM pgs_distribution_metadata.partition | ||
WHERE relation_id = table_relation_id; | ||
END; | ||
$sync_table_metadata_to_citus$ LANGUAGE 'plpgsql'; | ||
|
||
COMMENT ON FUNCTION sync_table_metadata_to_citus(text) | ||
IS 'synchronize a distributed table''s pg_shard metadata to CitusDB'; |
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
# pg_shard extension | ||
comment = 'extension for sharding across remote PostgreSQL servers' | ||
default_version = '1.0' | ||
default_version = '1.1' | ||
module_pathname = '$libdir/pg_shard' | ||
relocatable = true |
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So how does this work? Will both files be executed on a
CREATE EXTENSION
command?As I understand, and
ALTER EXTENSION UPDATE
on a 1.0 installation will add the new UDF.Should we be moving the UDF to the 1.1 file, and keeping the above line as pg_shard--1.1.sql only? If I run a
CREATE EXTENSION
, shouldn't I expect the 1.1 file to include everything?I'm not sure, so I'm just asking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the extension will come with exactly one version: 1.1. If you want 1.0 you'd download that version instead.
So for installing from scratch, the 1.1 script is used. For upgrading from 1.0, PostgreSQL will route a path from 1.0 to 1.1. Here it's trivial (a single file), so it'll execute that to perform the upgrade.
The UDF is already in the 1.1 file. We checked it into 1.0, but this Pull Request renames the file to 1.1. The 1.1 standalone file should include everything (double check for me).
It does. Don't think about the code in
develop
's history. Think about the history of releases. We released a 1.0 file in December. That's the only public install file so far. So for a 1.1 release we need two things:This change renames the "main" install file to 1.1, satisfying the first requirement above and adds the upgrade script, satisfying the second.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok. That part I didn't realize. For some reason, I thought the UDF was only in the 1.0-1.1.sql file. The rest of it makes sense then. I checked, and the 1.1 sql file looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last question then. The create-extension command also supports a version. If I specify create-extension version 1.0, would that work? (And create 1.0 without the UDF?)
After checking on that, and assuming we've tested 1.0-1.1 upgrade and a 1.1 fresh install, you're good to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only way to install version 1.0 would be to download 1.0 and use that. The state of affairs for our extensions seems to be: