This page describes how to configure database flags for Cloud SQL, and
lists the flags that you can set for your instance. You use database flags
for many operations, including adjusting PostgreSQL parameters, adjusting
options, and configuring and tuning an instance.
In some cases, setting one flag may require that you set another flag to
fully enable the functionality you want to use.
When you set, remove, or modify a flag for a database instance, the database
might be restarted. The flag value is then persisted for the instance until you
remove it. If the instance is the source of a replica, and the instance is
restarted, the replica is also restarted to align with the current configuration
of the instance.
Configure database flags
The following sections cover common flag management tasks.
Set a database flag
Console
In the Google Cloud console,
select the project that contains the Cloud SQL instance for which you want to set a database flag.
Open the instance and click Edit.
Go to the Flags section.
To set a flag that has not been set on the instance before, click
Add item, choose the flag from the drop-down menu, and set its value.
Click Save to save your changes.
Confirm your changes under Flags on the Overview page.
This command will overwrite all database flags
previously set. To keep those and add new ones, include the values for all
flags you want set on the instance; any flag not specifically included is
set to its default value. For flags that don't take a value, specify the
flag name followed by an equals sign ("=").
For example, to set the log_connections and
log_min_error_statement flags, you
can use the following command:
resource "google_sql_database_instance" "instance" {
name = "postgres-instance"
region = "us-central1"
database_version = "POSTGRES_14"
settings {
database_flags {
name = "log_connections"
value = "on"
}
database_flags {
name = "log_min_error_statement"
value = "error"
}
tier = "db-custom-2-7680"
}
# set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
# use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
deletion_protection = false
}
Apply the changes
To apply your Terraform configuration in a Google Cloud project, complete the steps in the
following sections.
Set the default Google Cloud project
where you want to apply your Terraform configurations.
You only need to run this command once per project, and you can run it in any directory.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Environment variables are overridden if you set explicit values in the Terraform
configuration file.
Prepare the directory
Each Terraform configuration file must have its own directory (also
called a root module).
In Cloud Shell, create a directory and a new
file within that directory. The filename must have the
.tf extension—for example main.tf. In this
tutorial, the file is referred to as main.tf.
mkdir DIRECTORY && cd DIRECTORY && touch main.tf
If you are following a tutorial, you can copy the sample code in each section or step.
Copy the sample code into the newly created main.tf.
Optionally, copy the code from GitHub. This is recommended
when the Terraform snippet is part of an end-to-end solution.
Review and modify the sample parameters to apply to your environment.
Save your changes.
Initialize Terraform. You only need to do this once per directory.
terraform init
Optionally, to use the latest Google provider version, include the -upgrade
option:
terraform init -upgrade
Apply the changes
Review the configuration and verify that the resources that Terraform is going to create or
update match your expectations:
terraform plan
Make corrections to the configuration as necessary.
Apply the Terraform configuration by running the following command and entering yes
at the prompt:
terraform apply
Wait until Terraform displays the "Apply complete!" message.
Open your Google Cloud project to view
the results. In the Google Cloud console, navigate to your resources in the UI to make sure
that Terraform has created or updated them.
Delete the changes
To delete your changes, do the following:
To disable deletion protection, in your Terraform configuration file set the
deletion_protection argument to false.
deletion_protection = "false"
Apply the updated Terraform configuration by running the following command and
entering yes at the prompt:
terraform apply
Remove resources previously applied with your Terraform configuration by running the following
command and entering yes at the prompt:
terraform destroy
REST v1
To set a flag for an existing database:
Before using any of the request data,
make the following replacements:
If there are existing flags configured for the database, modify the previous
command to include them. The PATCH command overwrites the existing
flags with the ones specified in the request.
REST v1beta4
To set a flag for an existing database:
Before using any of the request data,
make the following replacements:
If there are existing flags configured for the database, modify the previous
command to include them. The PATCH command overwrites the existing
flags with the ones specified in the request.
Clear all flags to their default values
Console
In the Google Cloud console,
select the project that contains the Cloud SQL instance for which you want to clear all flags.
Open the instance and click Edit.
Open the Database flags section.
Click the X next to all of the flags shown.
Click Save to save your changes.
gcloud
Clear all flags to their default values on an instance:
To view all current values of the PostgreSQL settings, log into
your instance with the psql client and enter the following statement:
SELECTname,settingFROMpg_settings;
Note that you can change the value only for supported flags (as listed below).
Determine which database flags have been set for an instance
To see which flags have been set for a Cloud SQL instance:
Console
In the Google Cloud console,
select the project that contains the Cloud SQL instance for which you want to see the database flags that have been set.
Select the instance to open its Instance Overview page.
The database flags that have been set are listed under the
Database flags section.
gcloud
Get the instance state:
gcloudsqlinstancesdescribeINSTANCE_NAME
In the output, database flags are listed under the settings as
the collection databaseFlags. For more information
about the representation of the flags in the output, see
Instances Resource Representation.
REST v1
To list flags configured for an instance:
Before using any of the request data,
make the following replacements:
project-id: The project ID
instance-id: The instance ID
HTTP method and URL:
GET https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id
To send your request, expand one of these options:
String debug5|debug4|debug3|debug2|debug1|debug| info|notice|warning|error|log|fatal|panic The default is warning.
Supported in PostgreSQL 10 and later.
integer The size range is from 10% - 70% of the instance's
memory.
Unit is 8 KB.
The default is 40% of VM memory. For example, for a
45GB instance memory, the default value is 18537160 KB.
String
A printf-style string that's generated at the beginning of each line of a log file.
The default is %m [%p]: [%l-1] db=%d,user=%u,
which logs timestamp, process ID, database, and username.
enumeration none | ddl | mod | all Set to mod to log all Data definition language (DDL)
statements, plus data-modifying statements such as INSERT, UPDATE, DELETE, TRUNCATE The default is none.
integer 14 ... varies (see note) The default value depends on the amount of memory of the largest
instance in the chain of primaries (this instance; and, if it's a read
replica, its primary, its primary's primary, etc. all the way up to the
root of the replication tree).
Memory (GB) on largest instance
Default value
tiny (~0.5)
25
small (~1.7)
50
from 3.75 to < 6
100
from 6 to < 7.5
200
from 7.5 to < 15
400
from 15 to < 30
500
from 30 to < 60
600
from 60 to < 120
800
>=120
1,000
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that
is lower than the new value on the primary, or that have not been changed from
the default value. Such changes on the primary cause the replica to restart.
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that
is lower than the new value on the primary, or that have not been changed from
the default value. Such changes on the primary cause the replica to restart.
integer 0 ... varies The default is 2.
Supported in PostgreSQL 11 and later.
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that's
lower than the new value on the primary, or that haven't been changed from
the default value.
If the value on the primary is default, then the value for the replicas can't be
changed. To change the value for the replicas, first, set the value on the primary to an integer.
integer 0 ... varies The default is 8.
Supported in PostgreSQL 10 and later.
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that's
lower than the new value on the primary, or that haven't been changed from
the default value.
If the value on the primary is default, then the value for the replicas can't be
changed. To change the value for the replicas, first, set the value on the primary to an integer.
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that's
lower than the new value on the primary, or that haven't been changed from
the default value.
If the value on the primary is default, then the value for the replicas can't be
changed. To change the value for the replicas, first, set the value on the primary to an integer.
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that
is lower than the new value on the primary, or that have not been changed from
the default value. Such changes on the primary cause the replica to restart.
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that
is lower than the new value on the primary, or that have not been changed from
the default value. Such changes on the primary cause the replica to restart.
The value on replicas must be greater than or equal to the value on the
primary. Changes on the primary propagate to replicas that have a value that
is lower than the new value on the primary, or that have not been changed from
the default value. Such changes on the primary cause the replica to restart.
The default depends on the PostgreSQL version. For PostgreSQL
versions 10 to 13, the default is md5. For PostgreSQL 14
and higher, the default is scram-sha-256.
enumeration debug5 |
debug4 | debug3 | debug2 |
debug1 | info | notice |
warning | error | log The default is log. Additionally,
pgaudit.log_level is enabled only when
pgaudit.log_client is on.
integer The size range is from 10% - 60% of the instance's
memory.
Unit is 8 KB.
The default is one-third of the instance's total VM memory (in MB).
For example, for 45 GB of instance memory, the default value is 15085MB.
enumeration Postgres 14: Sets the maximum SSL/TLS
protocol version to use. Valid values are as for
ssl_min_protocol_version, with the addition of an empty string,
which allows any protocol version to be specified.
Supported in PostgreSQL 12 and later.
enumeration Postgres 14: Sets the minimum SSL/TLS
protocol version to use. Valid values are currently: TLSv1,
TLSv1.1, TLSv1.2, TLSv1.3.
The default is TLSv1.
Supported in PostgreSQL 12 and later.
integer 0 ... 2147483647 The default is 60 seconds.
This flag affects the WAL sender and receiver.
If not appropriately set, this flag affects logical and physical
replication. This flag also affects replication performance and latency.
A value of zero disables the timeout mechanism. The unit is
milliseconds.
integer 0 ... 2147483647 The default is 60 seconds.
This flag affects the WAL sender and receiver.
If not appropriately set, this flag affects
logical and physical replication. This flag also affects replication
performance and latency. A value of zero disables the timeout mechanism.
The unit is milliseconds.
PostgreSQL has a background writer (bgwriter) flag. This flag issues writes of
new or modified shared buffers. These shared buffers are known as dirty buffers.
When the number of clean shared buffers is insufficient, the background writer
writes dirty buffers to the file system and marks them as clean.
Two flags associated with the bgwriter flag are bgwriter_delay and bgwriter_lru_maxpages. bgwriter_delay specifies the delay between activity
rounds for the background writer in milliseconds (ms), and bgwriter_lru_maxpages
specifies how many buffers will be written by the background writer.
The default value for the bgwriter flag is 200 ms. However, if
you select a solid state drive (SSD) that's greater than 500 GB, then the value
of the bgwriter_delay flag is set to 50, and the value of
the bgwriter_lru_maxpages flag is set to 200.
For more information about the background writer, see the PostgreSQL documentation.
session_replication_role
PostgreSQL has the session_replication_role flag, which is designed to be used
for logical replication and lets you disable constraint triggers in
individual sessions.
Sometimes this flag can also be used for some maintenance operations to
circumvent constraint (most often Foreign Key) checks.
This flag can be set in a session by any user which has the REPLICATION
property set. The REPLICATION property for any user can be set by
cloudsqlsuperuser when one of flags
cloudsql.enable_pglogical or
cloudsql.logical_decoding is set for the instance.
This flag can not be set for the whole instance.
Troubleshooting
Issue
Troubleshooting
You set the time zone for a session, but it expires when you log off.
Connect to the database and set the
database time zone to the one you want, either per user or per database.
In Cloud SQL for PostgreSQL, you can specify the following.
These settings remain after a session is closed, mimicking a
.conf configuration:
These settings apply only to new connections to the database. To see the
change to the time zone, disconnect from the instance and then reconnect to
it.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-12-15 UTC."],[],[]]
