Repository navigation
Edits for DDL replication/Mixed version prohibition - #6851
nidhibhammar merged 7 commits into
Conversation
djw-m
added
the
deploy
sumarjee
left a comment
sumarjee
left a comment
There was a problem hiding this comment.
This looks fine.
I assume you plan to have separate commit for adding a note at correct place under DDL replication section.
|
|
||
| * **Update the extensions** | ||
| * The upgrade process checks for extension updates and generates a script named `updated_extensions.sql` in the current directory if needed. | ||
| This contains `ALTER EXTENSION` commands for any extensions that need updating after the upgrade. As these are DDL commands, if you have to run the script before all nodes are upgraded, you should turn off DDL replication temporarily to avoid issues with mixed major versions. If you can defer running the script until all nodes are upgraded, you can run it on each node after the upgrade of that node is complete. |
There was a problem hiding this comment.
Note: possible gotcha here, if someone thinks "yay, I'll just SET bdr.ddl_replication=off before \i-ing the update script" - the update script contains a \c / \connection command for each database that pg_upgrade thinks has extensions which need upgrading, which will start a new session, rendering the SET bdr.ddl_replication=off ineffective, like this:
postgres=# SET bdr.ddl_replication = off;
SET
postgres=# SHOW bdr.ddl_replication ;
bdr.ddl_replication
---------------------
off
(1 row)
postgres=# \c postgres
psql (18devel, server 17.4)
You are now connected to database "postgres" as user "postgres".
postgres=# SHOW bdr.ddl_replication ;
bdr.ddl_replication
---------------------
on
(1 row)
There was a problem hiding this comment.
That's a good point. @sumarjee is there an answer to this problem or do we have to tell people they need to edit the script?
There was a problem hiding this comment.
I was not aware of this, we have to cross link to whatever way we recommend customer to turn off ddl_replication. @ibarwick can you please help with the correcting this as you have already explored on this.
There was a problem hiding this comment.
@ibarwick if it makes more sense to even not at all recommend running this script before all upgrades done, we can do that instead of having these problems..
There was a problem hiding this comment.
Added notes on how you can mitigate the issue manually but indicated its better left till afterwards.
djw-m
changed the title
694c804 to
132df59
Compare
|
@sumarjee, Can you please look at this PR and let us know if there any action items pending here or we are good to merge? |
|
@ibarwick can you please confirm the changes done till now are good to merge? |
Signed-off-by: Dj Walker-Morgan <dj.walker-morgan@enterprisedb.com>
Signed-off-by: Dj Walker-Morgan <dj.walker-morgan@enterprisedb.com>
Signed-off-by: Dj Walker-Morgan <dj.walker-morgan@enterprisedb.com>
Signed-off-by: Dj Walker-Morgan <dj.walker-morgan@enterprisedb.com>
Signed-off-by: Dj Walker-Morgan <dj.walker-morgan@enterprisedb.com>
6313917 to
4f2f0a5
Compare
This branch was previously deployed
4 participants
What Changed?
Added notes on the requirement not to perform DDL replication during mixed major version upgrades.