Update supautils.conf.j2 | added log_replication_commands to supautils

[TheOtherBrian1]

What kind of change does this PR introduce?

supautils update

What is the current behavior?

Cannot configure log_replication_commands

What is the new behavior?

Added log_replication_commands to the list

Additional context

This should work with replicas because it's set at the role level. Context:

• https://supabase.slack.com/archives/C02FHG9QQAF/p1734626738133839

[samrose]

@TheOtherBrian1 I wonder what we can do to resolve this one? Still waiting for review?

[TheOtherBrian1]

@samrose, it's been a few weeks since I looked at this. Yeah, I'm still waiting for a review. The original ticket that prompted the PR was from an enterprise customer that was having trouble debugging their replication. With Postgres 17 coming out soon, this option can better enable users to self-manage

[samrose]

@doublethink @staaldraad @darora @pcnc @olirice @soedirgo

Can you take a look at this and see if you have any concerns about compliance or security leakage around enabling log_replication_commands for privileged roles please?

[staaldraad]

@doublethink @staaldraad @darora @pcnc @olirice @soedirgo

Can you take a look at this and see if you have any concerns about compliance or security leakage around enabling log_replication_commands for privileged roles please?

I think we are good with enabling this without too much risk.

[soedirgo]

Also OK with enabling this

[darora]

Is it desirable to be setting all of these at the role level?

No particular objection to allowing it, but we keep permitting config here that in a lot of cases makes more sense to set at the DB level (e.g. auto_explain, log_lock_waits, log_min_duration)

[soedirgo]

Is it desirable to be setting all of these at the role level?

No strong preference for either approach, but setting it at the role level is marginally safer (e.g. no undesired config changes on internal roles)

[darora]

No strong preference for either approach, but setting it at the role level is marginally safer (e.g. no undesired config changes on internal roles)

Safer, yes, but less useful (e.g. would you not want log_lock_waits set for pgrst usage?). In any case, doesn't block this particular change.