Modify aws_db_instance and delete aws_db_parameter_group breaks

[jrobison-sb]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

$ terraform -v
Terraform v0.11.8
+ provider.aws v1.41.0

Affected Resource(s)

• aws_db_parameter_group
• aws_db_instance

Terraform Configuration Files

If I have a running RDS instance which is using a DB parameter group, and I want to modify the DB instance to use a different parameter group, and delete the old parameter group, I'll get a TF plan which looks like this:

  ~ module.my_module.aws_db_instance.application
      parameter_group_name: "pg10-foo" => "pg10-bar"

  - module.my_module.aws_db_parameter_group.foo

Expected Behavior

Modify the RDS instance, then delete the parameter group which is now unused.

Actual Behavior

It tries to delete the parameter group first, which fails because the parameter group is still in use.

InvalidDBParameterGroupState: One or more database instances are still members of this parameter group pg10-foo, so the group cannot be deleted

If it would have done the modify action first on the DB instance, it would then be able to do the destroy action on the now unused parameter group.

Steps to Reproduce

Run a plan which plans to modify a DB instance to change the parameter group to some other parameter group, and which also plans to delete the now unused parameter group.

[bflad]

Hi @jrobison-sb 👋 Thanks for reporting this and sorry for the trouble.

Can you confirm a few pieces of information here?

• Are you using a reference such as parameter_group_name = "${aws_db_parameter_group.foo.name}" in your aws_db_instance configuration?
• Is apply_immediately set to true in the aws_db_instance configuration?
• What is the state of the RDS instance after this apply? Is the parameter group changed? Does it say pending-reboot in the console for the parameter group?

Without seeing the debug log here its not possible to tell definitively, but my initial hunch is that the operations are happening in order, but that the parameter group change is requiring an instance reboot still, something which the Update function of aws_db_instance does not do currently. Since the parameter group update isn't successfully completed by the instance, the parameter group is stuck.

If you would like to see the debug log yourself or provide it for reference in this issue via a Gist, documentation can be found here: https://www.terraform.io/docs/internals/debugging.html

Please let us know about the items above and hopefully we can dig into this further, thanks.

[jrobison-sb]

@bflad Thanks for your fast response. I'll answer each of your questions below.

Are you using a reference such as parameter_group_name = "${aws_db_parameter_group.foo.name}" in your aws_db_instance configuration?

I'm using aws_db_parameter_group.foo.id, but close enough, yes.

Is apply_immediately set to true in the aws_db_instance configuration?

Yes.

What is the state of the RDS instance after this apply? Is the parameter group changed? Does it say pending-reboot in the console for the parameter group?

No, the RDS instance is unchanged, and still using the old parameter group. Since the RDS instance wasn't changed, there is no pending-reboot needed.

As for a debug log, my module has hundreds (or more) of resources, and a full debug log is 128,000 lines, so I'm hesitant to publicly post that. If it's highly necessary, let me know, and maybe I can creatively grep or parse through it somehow.

[ghost]

I'm experiencing what may be the same problem. It looks like the modification simply does not happen in my case. After an apply, the parameter group used by my instance is still the original one: default.postgres9.5 (in-sync). There is no pending reboot on the instance either.

If you remove the deletion of your old group, does the modification actually happen at all?

[rdonkin]

I'm having the same issue when trying to upgrade from Postgres 10.6 to 11.1 on RDS. As with @liamg-form3 the parameter group remains the original one.

My code doesn't explicitly delete the parameter group, the only change was to upgrade the engine version and use a new postgres11 family for the parameter group. I'm using the terraform-aws-rds module.

This workaround has worked fine on several instances with the same issue:

• Run Terraform, get the error above about parameter group
• Reboot the DB instance - after reboot, will be on the new version, and using the new parameter group from postgres11 family
• Run Terraform again to ensure the old parameter group is deleted

Not very elegant but quite easy to do, and some downtime is required anyway with RDS when upgrading Postgres.

[bflad]

I believe the key here is:

Reboot the DB instance

After calling ModifyDBInstance. We had done a similar fix during resource creation with snapshots (#5672), but looks look we also need to do something similar during update.

[eporomaa]

We got stuck trying to change the parameter group (PG) of our Postgres DB. The error msg:
Error: Error deleting DB parameter group: InvalidDBParameterGroupState: One or more database instances are still members of this parameter group [our PG name], so the group cannot be deleted

Assuming we want to change from PG A -> B our workaround solution for this was.

1. Via AWS ui manually create a copy of the PG A called C.
2. Comment out the RDS dependancy on PG in main.tf:

// parameter_group_name = aws_db_parameter_group.default.id

3. Via AWS ui change RDS to use PG C.
4. Run terraform apply, this could now successfully replace A -> B since A is not used by RDS.
5. In our main.tf file switch back the requirement on PG (Which now is B).
6. Running terraform apply RDS can now pick up the PG and the terraform state is in sync with our real state.
7. Manually remove the PG C.

Hope this helps someone in the future.

[rightisleft]

I also encountered this while trying to change the name of a db param group

Plan:

-/+ resource "aws_db_parameter_group" "scuba" {
      ~ arn         = "arn:aws:rds:xxxxxxxxxxxxxx" -> (known after apply)
        description = "Managed by Terraform"
        family      = "postgres11"
      ~ id          = "xxxxxx-postgres-11" -> (known after apply)
      ~ name        = "xxxxxx-postgres-11" -> "yyyyyy-postgres-11" # forces replacement
      + name_prefix = (known after apply)
      - tags        = {} -> null

        parameter {
            apply_method = "immediate"
            name         = "temp_file_limit"
            value        = "2147483647"
        }
        parameter {
            apply_method = "immediate"
            name         = "work_mem"
            value        = "65536"
        }
    }

aws_db_parameter_group.xxxxx: Still destroying... [id=xxxxx-postgres-11, 2m40s elapsed]
aws_db_parameter_group.xxxxx: Still destroying... [id=xxxxx-postgres-11, 2m50s elapsed]

Error: Error deleting DB parameter group: InvalidDBParameterGroupState: One or more database instances are still members of this parameter group xxxxx-postgres-11, so the group cannot be deleted
	status code: 400, request id: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

Action:
I saw the rds instance was marked as ready-for-reboot, manually rebooted the instance.
Impact:
No change - same results as above.

Action:
Created a backup of the xxx database group. Tried to delete the xxxxx-postgres-11 database group.
Impact:
Failed to delete xxxxx-postgres-11: One or more database instances are still members of this parameter group xxxxx-postgres-11, so the group cannot be deleted (Service: AmazonRDS; Status Code: 400; Error Code: InvalidDBParameterGroupState; Request ID: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx).

Action:

1. Logged into the AWS Console
2. modified the actual RDS instance back to the default.postgres11 group provided by AWS
3. re ran terraform apply

Impact: Worked. Once the group was no longer actively assigned to a database, terraform could rename the custom xxxxx-postgres-11 to yyyy-postgres-11 database group. TF then swapped the default.postgres.11 group for the yyyy-postgres-11 group by applying the change immediately.

Suggestion:
Looks like terraform needs to assign to a temporary or default group to the RDS instance prior to modifying the aws_db_parameter_group. Upon completion, restore the intended group.

[pzi123]

The same issue 2 years after. No RDS cleanup/destroy possible:

Error: InvalidDBParameterGroupState: One or more database instances are still members of this parameter group ambari-hdf-peterz, so the group cannot be deleted
status code: 400, request id: 64d52b07-e31d-4355-89a6-76755072a433

Error: error deleting RDS Cluster (ambari-hdf-peterz): DBClusterSnapshotAlreadyExistsFault: Cannot create the cluster snapshot because one with the identifier ambari-hdf-final-snapshot already exists.
status code: 400, request id: 58b59224-5a06-4586-b6dc-4d9ab62ead67

Error: Error deleting DB parameter group: InvalidDBParameterGroupState: One or more database instances are still members of this parameter group xxxxx, so the group cannot be deleted
status code: 400, request id: xxxxxx

[terragrunt] 2020/06/19 12:37:01 Hit multiple errors:
exit status 1

[ku9n]

Hi guys, I agree with the previous comment. This causes problems in the automation and use of pipelines. In my case, when using Jenkins. Removing or modifying RDS is impossible in those tasks that pursue terraforms. Unfortunately, I can not offer a solution to the problem in the form of code, I can only assume that this option will work:

1. Rollback to the default RDS group
2. Deleting a parameter group
3. Removing RDS

Here is our code:

resource "aws_db_parameter_group" "pg" {
name = "paramg"
family = "mysql5.7"

parameter {
name = "log_bin_trust_function_creators"
value = "1"
}
}
resource "aws_db_instance" "db" {
allocated_storage = 30 # gigabytes
backup_retention_period = 7 # in days
engine = "mysql"
engine_version = "5.7"
identifier = "db"
instance_class = "db.t3.small"
multi_az = true
name = "mydb"
password = "password"
port = 5465
storage_type = "gp2"
username = "devops"
vpc_security_group_ids = ["${aws_security_group.DB-SG.id}"]
parameter_group_name = "paramg"
skip_final_snapshot = true
}

I understand that there are workarounds using AWS console, but agree that this is not a solution to this problem.

Reaction to destroy:

Error deleting DB parameter group: InvalidDBParameterGroupState: One or more database instances are still members of this parameter group paramg, so the group cannot be deleted
status code: 400, request id: xxxxxxx-xxxxxx-xxxxxxx-xxxxxxxx-xxxxxxxxxx

Then the pipeline will not move.
This problem also reproduces with command-line commands.
It doesn't matter whether it is enabled or not apply_imediately.
If I missed something, please correct me.
Thank you. Regards.

UPD
This problem can be fooled. In the case of Jenkins, we reset the error of the first destruction and immediately launch the second in this way:

    stage('Terraform Destroy') {
      steps {
        input 'Destroy Plan'
        catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
        sh "${env.TERRAFORM_HOME}/terraform destroy -force -input=false"
        }
      }
    }
    stage('Terraform second Destroy') {
      steps {
        input 'Destroy Plan'
        sh "${env.TERRAFORM_HOME}/terraform destroy -force -input=false"
      }
    }
  }
}

I hope it will be useful to someone.

[CumpsD]

This is preventing me to upgrade a SQL Server 2017 to 2019 on RDS.

[juliosantos]

Can't move the postgres engine version on RDS because of this :(

[johnmarcou]

You want to use this snippet on the aws_db_parameter_group:

lifecycle {
    create_before_destroy = true
  }

This will create the new DB parameter group, update the DB, and finally delete the old parameter group.
You might need to use name_prefix instead of name to avoid collision as well.

[azhurbilo]

name_prefix and create_before_destroy = true in theory should work (we have upgraded some DBs with no issues) 👍
but today we faced with failed terraform apply :(

aws_rds_cluster_parameter_group.default[0]: Creation complete after 1s [id=xxx-20211122151251039100000001]
aws_rds_cluster.default[0]: Modifying... [id=xxx]
aws_rds_cluster.default[0]: Still modifying... [id=xxx, 10s elapsed]
aws_rds_cluster.default[0]: Still modifying... [id=xxx, 20s elapsed]
aws_rds_cluster.default[0]: Still modifying... [id=xxx, 30s elapsed]
aws_rds_cluster.default[0]: Modifications complete after 31s [id=xxx]
aws_rds_cluster_instance.default[0]: Modifying... [id=xxx]
aws_rds_cluster_instance.default[0]: Modifications complete after 0s [id=xxx]
aws_rds_cluster_parameter_group.default[0]: Destroying... [id=xxx-20211021125946599700000001]
Error: InvalidDBParameterGroupState: One or more database instances are still members of this parameter group xxx-20211021125946599700000001, so the group cannot be deleted
   status code: 400

maybe there is no additional check that instances are updated too (Available state) aws_rds_cluster_instance.default[0]: Modifications complete after 0s [id=xxx]
0 seconds

[gitkent]

Along with create_before_destroy = true, we are also using time_sleep to workaround on delayed destroy of DB parameter group: https://registry.terraform.io/providers/hashicorp/time/latest/docs/resources/sleep#delay-destroy-usage

[pnjha]

create_before_destroy = true does not work sometimes due to a bug that does not wait for engine_version update to complete and reports upgrade complete even when in the backend the instance is still in modifying state. Due to this, the delete of the old DB parameter group fails.
Check this bug: #24908

[hoangminhtu-dh]

I came across this today but the underlying root cause was different from the ones listed above. We tried upgrading an RDS PostgreSQL instance from 11.13 to 12.10 and the modification was printed out as completed:

  # module.db.aws_db_instance.main[0] will be updated in-place
  ~ resource "aws_db_instance" "main" {
      ~ engine_version       = "11.13" -> "12.10"
      ~ parameter_group_name = "production-<redacted>-api-11" -> "production-<redacted>-api-12"
        # (50 unchanged attributes hidden)
    }

module.db.aws_db_instance.main[0]: Modifications complete after 4m24s [id=production-<redacted>-api]

However, checking the TF state for this resource, it is still on version 11.13:

# module.db.aws_db_instance.main[0]:
resource "aws_db_instance" "main" {
    engine                                = "postgres"
    engine_version                        = "11.13"
    engine_version_actual                 = "11.13"
}

Upon visiting AWS Console > RDS > Database > this instance > Logs & events > Recent events & navigate to the last tab:

Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: The instance could not be upgraded because one or more databases have settings or usages that are not compatible with the target engine version. Please check the precheck log file for more details

And upon checking the logs that is under this:

The instance could not be upgraded from 11.13.R1 to 12.10.R1 because of following reasons. Please take appropriate action on databases that have usages incompatible with requested major engine version upgrade and try again.
- Following usages in database '<redacted>' need to be corrected before upgrade:
-- The instance could not be upgraded because there are one or more databases with an older version of PostGIS extension or its dependent extensions (<redacted>) installed. Please upgrade all installations of PostGIS and drop its dependent extensions and try again.

So it's a tad unexpected that a failed/incomplete upgrade operation reported as successful (Modifications complete) with Terraform and/or the AWS API. I might need to turn on debug mode (similar to #24908 (comment)) in order to see what exactly was returned from the AWS API so that Terraform mistook this for a successful operation.

But yeah, posting this here just in case other peeps are running into the same situation and scratch your head repeatedly at the (slightly) wrong places.

[jar-b]

The following situations were tested with a minimal configuration using Postgres and a custom parameter group with create_before_destroy lifecycle configuration.

• Parameter group replacement with new group
• Parameter group name_prefix change
• Minor version engine upgrade + parameter group name_prefix change
• Major version engine upgrade + parameter group family upgrade

In each case, the create_before_destroy directive prevented destruction of the in-use parameter group, and resulted in a successful first time apply. Given this solution has also worked for some practitioners based on this issue's comments, a proposed resolution to this issue is to add documentation around this lifecycle argument in the context of the aws_db_parameter_group resource.

To allow time for feedback on the reproduction and documentation changes, we're going to leave this issue open. If no objections are received we will close this as completed in the near future.

A more detailed breakdown of the minimal reproduction is included below:

Config

Show

Parameter group swap (original issue)

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {}


#resource "aws_db_parameter_group" "repro" {
  #name_prefix = "jb-test"
  #family      = "postgres13"

  #parameter {
    #name  = "log_connections"
    #value = "1"
  #}

  #lifecycle {
    #create_before_destroy = true
  #}
#}

resource "aws_db_parameter_group" "repro-new" {
  name_prefix = "jb-test-new"
  family      = "postgres13"

  parameter {
    name  = "log_connections"
    value = "1"
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_db_instance" "repro" {
  identifier           = "jb-test"
  instance_class       = "db.t3.micro"
  allocated_storage    = 10
  engine               = "postgres"
  engine_version       = "13.7"
  username             = "jb"
  password             = "testtest"
  parameter_group_name = aws_db_parameter_group.repro-new.name # was: aws_db_parameter_group.repro.name

  apply_immediately           = true
  allow_major_version_upgrade = true
  skip_final_snapshot         = true
  backup_retention_period     = 1
}

Engine version upgrade (subsequent comments)

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {}


resource "aws_db_parameter_group" "repro" {
  name_prefix = "jb-test" # "jb-test-nameupdate"
  family      = "postgres13" # "postgres12"

  parameter {
    name  = "log_connections"
    value = "1"
  }

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_db_instance" "repro" {
  identifier           = "jb-test"
  instance_class       = "db.t3.micro"
  allocated_storage    = 10
  engine               = "postgres"
  engine_version       = "13.7" # "12.7", "12.8"
  username             = "jb"
  password             = "testtest"
  parameter_group_name = aws_db_parameter_group.repro.name

  apply_immediately           = true
  allow_major_version_upgrade = true
  skip_final_snapshot         = true
  backup_retention_period     = 1
}

Reproduction Details

Show

$ terraform -v
Terraform v1.3.3
on darwin_arm64
+ provider registry.terraform.io/hashicorp/aws v4.36.1

Parameter group replacement with new group

$ terraform apply -auto-approve
aws_db_parameter_group.repro: Refreshing state... [id=jb-test20221026190006702200000001]
aws_db_instance.repro: Refreshing state... [id=jb-test]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create
  ~ update in-place
  - destroy

Terraform will perform the following actions:

  # aws_db_instance.repro will be updated in-place
  ~ resource "aws_db_instance" "repro" {
        id                                    = "jb-test"
      ~ parameter_group_name                  = "jb-test20221026190006702200000001" -> (known after apply)
        tags                                  = {}
        # (48 unchanged attributes hidden)
    }

  # aws_db_parameter_group.repro will be destroyed
  # (because aws_db_parameter_group.repro is not in configuration)
  - resource "aws_db_parameter_group" "repro" {
      - arn         = "arn:aws:rds:us-west-2:<account-id>:pg:jb-test20221026190006702200000001" -> null
      - description = "Managed by Terraform" -> null
      - family      = "postgres13" -> null
      - id          = "jb-test20221026190006702200000001" -> null
      - name        = "jb-test20221026190006702200000001" -> null
      - name_prefix = "jb-test" -> null
      - tags        = {} -> null
      - tags_all    = {} -> null

      - parameter {
          - apply_method = "immediate" -> null
          - name         = "log_connections" -> null
          - value        = "1" -> null
        }
    }

  # aws_db_parameter_group.repro-new will be created
  + resource "aws_db_parameter_group" "repro-new" {
      + arn         = (known after apply)
      + description = "Managed by Terraform"
      + family      = "postgres13"
      + id          = (known after apply)
      + name        = (known after apply)
      + name_prefix = "jb-test-new"
      + tags_all    = (known after apply)

      + parameter {
          + apply_method = "immediate"
          + name         = "log_connections"
          + value        = "1"
        }
    }

Plan: 1 to add, 1 to change, 1 to destroy.
aws_db_parameter_group.repro-new: Creating...
aws_db_parameter_group.repro-new: Creation complete after 3s [id=jb-test-new20221026192236273200000001]
aws_db_instance.repro: Modifying... [id=jb-test]
aws_db_instance.repro: Still modifying... [id=jb-test, 10s elapsed]
...
aws_db_instance.repro: Still modifying... [id=jb-test, 1m40s elapsed]
aws_db_instance.repro: Modifications complete after 1m42s [id=jb-test]
aws_db_parameter_group.repro: Destroying... [id=jb-test20221026190006702200000001]
aws_db_parameter_group.repro: Destruction complete after 1s

Apply complete! Resources: 1 added, 1 changed, 1 destroyed.

Parameter group name_prefix change

$ terraform apply -auto-approve
aws_db_parameter_group.repro: Refreshing state... [id=jb-test20221026175055326400000001]
aws_db_instance.repro: Refreshing state... [id=jb-test]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place
+/- create replacement and then destroy

Terraform will perform the following actions:

  # aws_db_instance.repro will be updated in-place
  ~ resource "aws_db_instance" "repro" {
        id                                    = "jb-test"
      ~ parameter_group_name                  = "jb-test20221026175055326400000001" -> (known after apply)
        tags                                  = {}
        # (48 unchanged attributes hidden)
    }

  # aws_db_parameter_group.repro must be replaced
+/- resource "aws_db_parameter_group" "repro" {
      ~ arn         = "arn:aws:rds:us-west-2:<account-id>:pg:jb-test20221026175055326400000001" -> (known after apply)
      ~ id          = "jb-test20221026175055326400000001" -> (known after apply)
      ~ name        = "jb-test20221026175055326400000001" -> (known after apply)
      ~ name_prefix = "jb-test" -> "jb-test-nameupdate" # forces replacement
      - tags        = {} -> null
      ~ tags_all    = {} -> (known after apply)
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 1 to add, 1 to change, 1 to destroy.
aws_db_parameter_group.repro: Creating...
aws_db_parameter_group.repro: Creation complete after 2s [id=jb-test-nameupdate20221026181552324300000001]
aws_db_instance.repro: Modifying... [id=jb-test]
aws_db_instance.repro: Still modifying... [id=jb-test, 10s elapsed]
...
aws_db_instance.repro: Still modifying... [id=jb-test, 1m50s elapsed]
aws_db_instance.repro: Modifications complete after 1m52s [id=jb-test]
aws_db_parameter_group.repro (deposed object f44351d0): Destroying... [id=jb-test20221026175055326400000001]
aws_db_parameter_group.repro: Destruction complete after 0s

Apply complete! Resources: 1 added, 1 changed, 1 destroyed.

Minor version engine upgrade

$ terraform apply -auto-approve
aws_db_parameter_group.repro: Refreshing state... [id=jb-test-new20221026152940374700000001]
aws_db_instance.repro: Refreshing state... [id=jb-test]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place
+/- create replacement and then destroy

Terraform will perform the following actions:

  # aws_db_instance.repro will be updated in-place
  ~ resource "aws_db_instance" "repro" {
      ~ engine_version                        = "12.7" -> "12.8"
        id                                    = "jb-test"
      ~ parameter_group_name                  = "jb-test-new20221026152940374700000001" -> (known after apply)
        tags                                  = {}
        # (47 unchanged attributes hidden)
    }

  # aws_db_parameter_group.repro must be replaced
+/- resource "aws_db_parameter_group" "repro" {
      ~ arn         = "arn:aws:rds:us-west-2:<account-id>:pg:jb-test-new20221026152940374700000001" -> (known after apply)
      ~ id          = "jb-test-new20221026152940374700000001" -> (known after apply)
      ~ name        = "jb-test-new20221026152940374700000001" -> (known after apply)
      ~ name_prefix = "jb-test-new" -> "jb-test" # forces replacement
      - tags        = {} -> null
      ~ tags_all    = {} -> (known after apply)
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 1 to add, 1 to change, 1 to destroy.
aws_db_parameter_group.repro: Creating...
aws_db_parameter_group.repro: Creation complete after 2s [id=jb-test20221026154901009300000001]
aws_db_instance.repro: Modifying... [id=jb-test]
aws_db_instance.repro: Still modifying... [id=jb-test, 10s elapsed]
...
aws_db_instance.repro: Still modifying... [id=jb-test, 16m54s elapsed]
aws_db_instance.repro: Modifications complete after 16m58s [id=jb-test]
aws_db_parameter_group.repro (deposed object 2431087f): Destroying... [id=jb-test-new20221026152940374700000001]
aws_db_parameter_group.repro: Destruction complete after 0s

Apply complete! Resources: 1 added, 1 changed, 1 destroyed.

Major version engine upgrade

$ terraform apply -auto-approve
aws_db_parameter_group.repro: Refreshing state... [id=jb-test20221026154901009300000001]
aws_db_instance.repro: Refreshing state... [id=jb-test]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place
+/- create replacement and then destroy

Terraform will perform the following actions:

  # aws_db_instance.repro will be updated in-place
  ~ resource "aws_db_instance" "repro" {
      ~ engine_version                        = "12.8" -> "13.7"
        id                                    = "jb-test"
      ~ parameter_group_name                  = "jb-test20221026154901009300000001" -> (known after apply)
        tags                                  = {}
        # (47 unchanged attributes hidden)
    }

  # aws_db_parameter_group.repro must be replaced
+/- resource "aws_db_parameter_group" "repro" {
      ~ arn         = "arn:aws:rds:us-west-2:<account-id>:pg:jb-test20221026154901009300000001" -> (known after apply)
      ~ family      = "postgres12" -> "postgres13" # forces replacement
      ~ id          = "jb-test20221026154901009300000001" -> (known after apply)
      ~ name        = "jb-test20221026154901009300000001" -> (known after apply)
      - tags        = {} -> null
      ~ tags_all    = {} -> (known after apply)
        # (2 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 1 to add, 1 to change, 1 to destroy.
aws_db_parameter_group.repro: Creating...
aws_db_parameter_group.repro: Creation complete after 2s [id=jb-test20221026175055326400000001]
aws_db_instance.repro: Modifying... [id=jb-test]
aws_db_instance.repro: Still modifying... [id=jb-test, 10s elapsed]
...
aws_db_instance.repro: Still modifying... [id=jb-test, 18m20s elapsed]
aws_db_instance.repro: Modifications complete after 18m23s [id=jb-test]
aws_db_parameter_group.repro (deposed object 8e7ac9c5): Destroying... [id=jb-test20221026154901009300000001]
aws_db_parameter_group.repro: Destruction complete after 0s

Apply complete! Resources: 1 added, 1 changed, 1 destroyed.

[breathingdust]

Closing given no further response to reproductions and documentation changes.

[Kristin0]

Error: Error creating DB Cluster Parameter Group: DBParameterGroupAlreadyExists: Parameter group **** already exists

when i am using

lifecycle {
create_before_destroy = true
}

[jrobison-sb]

@Kristin0 if AWS won't let you have two parameter groups with the same name, then you either need to use name_prefix instead of using name, or you need to stop using create_before_destroy = true.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.