feat(db): add new parameter group for db version update#2750
Conversation
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe pull request updates the RDS parameter group configuration for the production macrodb stack from PostgreSQL 14 to PostgreSQL 16. It introduces a legacy parameter group reference while conditionally creating a new v16 parameter group for production environments, with corresponding updates to stack configuration and infrastructure code. Changes
Possibly related PRs
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@infra/stacks/macrodb/index.ts`:
- Around line 60-94: The parameters array is duplicated between
originalParameterGroup and the new 'parameter-group-v16' resource; extract that
array into a single const (e.g., dbParameterSettings) and reuse it in both the
originalParameterGroup and the creation of the ParameterGroup named
'parameter-group-v16'; additionally capture the v16 ParameterGroup when you
construct it (assign to a variable) and export its ARN/name (similar to
parameterGroupArn) so downstream stacks can reference the new v16 group. Ensure
you update the ParameterGroup constructor to reference the shared
dbParameterSettings and add an exported constant like parameterGroupV16Arn (or
parameterGroupV16Name) pointing to the new resource's arn/name.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 504a4480-5e8a-49ae-b416-a227fa9d454f
📒 Files selected for processing (2)
infra/stacks/macrodb/Pulumi.prod.yamlinfra/stacks/macrodb/index.ts
| if (stack === 'prod') { | ||
| new aws.rds.ParameterGroup( | ||
| 'parameter-group-v16', | ||
| { | ||
| name: `macro-db-parameter-group-v16-${stack}`, | ||
| family: config.require('parameter_group_family'), | ||
| description: `Custom parameter group (${config.require('parameter_group_family')}) for macro-db-${stack}`, | ||
| parameters: [ | ||
| { name: 'checkpoint_timeout', value: '900' }, | ||
| { name: 'max_wal_size', value: '16384' }, | ||
| { name: 'min_wal_size', value: '4096' }, | ||
| { name: 'vacuum_cost_page_miss', value: '10' }, | ||
| { | ||
| name: 'shared_preload_libraries', | ||
| value: 'pg_stat_statements,auto_explain', | ||
| applyMethod: 'pending-reboot', | ||
| }, | ||
| { name: 'auto_explain.log_format', value: 'json' }, | ||
| { name: 'auto_explain.log_min_duration', value: '1000' }, | ||
| { name: 'auto_explain.log_analyze', value: 'on' }, | ||
| { name: 'auto_explain.log_buffers', value: 'on' }, | ||
| { name: 'auto_explain.log_timing', value: 'off' }, | ||
| { name: 'auto_explain.log_triggers', value: 'on' }, | ||
| { name: 'auto_explain.log_verbose', value: 'on' }, | ||
| { name: 'auto_explain.log_nested_statements', value: 'on' }, | ||
| { name: 'auto_explain.sample_rate', value: '1' }, | ||
| { name: 'idle_in_transaction_session_timeout', value: '300000' }, | ||
| ], | ||
| tags, | ||
| }, | ||
| { protect: true } | ||
| ); | ||
| } | ||
|
|
||
| export const parameterGroupArn = originalParameterGroup.arn; |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Extract the shared parameters array and consider exporting the v16 parameter group.
Two things worth addressing in this block:
- The
parametersarray (lines 67–87) is byte-for-byte identical to the one inoriginalParameterGroup(lines 33–53). Keeping two copies in sync by hand is a footgun — any future tuning (e.g.auto_explain.*,max_wal_size) will silently drift between the legacy PG14 and the new PG16 group. Lift it into a singleconstand reuse. As per coding guidelines "Eliminate redundant code and abstractions". parameter-group-v16is created but never captured in a variable or exported. Since the intent is to cut thedatabase/readReplicaover to it in a follow-up, andparameterGroupArnis already a stack output for the legacy group, it would be consistent to expose the v16 ARN/name the same way so downstream stacks (and the upgrade PR) have a stable reference. As per coding guidelines "Ensure stack outputs are documented and referenced correctly across stacks".
♻️ Proposed refactor
+const dbParameters: aws.rds.ParameterGroupArgs['parameters'] = [
+ { name: 'checkpoint_timeout', value: '900' },
+ { name: 'max_wal_size', value: '16384' },
+ { name: 'min_wal_size', value: '4096' },
+ { name: 'vacuum_cost_page_miss', value: '10' },
+ {
+ name: 'shared_preload_libraries',
+ value: 'pg_stat_statements,auto_explain',
+ applyMethod: 'pending-reboot',
+ },
+ { name: 'auto_explain.log_format', value: 'json' },
+ { name: 'auto_explain.log_min_duration', value: '1000' },
+ { name: 'auto_explain.log_analyze', value: 'on' },
+ { name: 'auto_explain.log_buffers', value: 'on' },
+ { name: 'auto_explain.log_timing', value: 'off' },
+ { name: 'auto_explain.log_triggers', value: 'on' },
+ { name: 'auto_explain.log_verbose', value: 'on' },
+ { name: 'auto_explain.log_nested_statements', value: 'on' },
+ { name: 'auto_explain.sample_rate', value: '1' },
+ { name: 'idle_in_transaction_session_timeout', value: '300000' },
+];
+
const originalParameterGroup = new aws.rds.ParameterGroup(
'parameter-group',
{
name: `macro-db-parameter-group-${stack}`,
family: parameterGroupFamily,
description: `Custom parameter group for macro-db-${stack}`,
- parameters: [
- { name: 'checkpoint_timeout', value: '900' },
- /* ...snip... */
- { name: 'idle_in_transaction_session_timeout', value: '300000' },
- ],
+ parameters: dbParameters,
tags,
},
{ protect: true }
);
-// For prod, we need to create a "new" parameter group for postgres 16 family
-if (stack === 'prod') {
- new aws.rds.ParameterGroup(
- 'parameter-group-v16',
- {
- name: `macro-db-parameter-group-v16-${stack}`,
- family: config.require('parameter_group_family'),
- description: `Custom parameter group (${config.require('parameter_group_family')}) for macro-db-${stack}`,
- parameters: [ /* duplicated list */ ],
- tags,
- },
- { protect: true }
- );
-}
-
-export const parameterGroupArn = originalParameterGroup.arn;
+// For prod, pre-create the postgres 16 parameter group so a later PR can cut
+// the instance and read replica over without destroying the legacy PG14 group.
+const v16ParameterGroup =
+ stack === 'prod'
+ ? new aws.rds.ParameterGroup(
+ 'parameter-group-v16',
+ {
+ name: `macro-db-parameter-group-v16-${stack}`,
+ family: config.require('parameter_group_family'),
+ description: `Custom parameter group (${config.require('parameter_group_family')}) for macro-db-${stack}`,
+ parameters: dbParameters,
+ tags,
+ },
+ { protect: true }
+ )
+ : undefined;
+
+export const parameterGroupArn = originalParameterGroup.arn;
+export const v16ParameterGroupArn = v16ParameterGroup?.arn;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@infra/stacks/macrodb/index.ts` around lines 60 - 94, The parameters array is
duplicated between originalParameterGroup and the new 'parameter-group-v16'
resource; extract that array into a single const (e.g., dbParameterSettings) and
reuse it in both the originalParameterGroup and the creation of the
ParameterGroup named 'parameter-group-v16'; additionally capture the v16
ParameterGroup when you construct it (assign to a variable) and export its
ARN/name (similar to parameterGroupArn) so downstream stacks can reference the
new v16 group. Ensure you update the ParameterGroup constructor to reference the
shared dbParameterSettings and add an exported constant like
parameterGroupV16Arn (or parameterGroupV16Name) pointing to the new resource's
arn/name.
No description provided.