Configuration parameters (GUCs) v16
These Grand Unified Configuration (GUC) configuration parameters are available with EDB Postgres Extended Server.
Backend parameters introduce a test probe point infrastructure for injecting sleeps or errors into PostgreSQL and extensions.
PROBE_POINT defined throughout the Postgres code code marks important code paths. These probe points might be activated to signal the current backend or to elog(...) a
PANIC. They might also, or instead, add a delay at that point in the code.
Unless explicitly activated, probe points have no effect and add only a single optimizer-hinted branch, so they're safe on hot paths.
When an active probe point is hit and the counter is satisfied, after any specified sleep interval, a log message is always emitted at
DEBUG1 or higher.
The name of a
PROBE_POINT in the code of 2ndQPostgres or in an extension that defines a
PROBE_POINT. This parameter isn't validated. If a nonexistent probe point is named, it's never hit.
Only one probe point can be active. This isn't a list, and attempting to supply a list means nothing matches.
Probe points generally have a unique name, given as the argument to the
PROBE_POINT macro in the code where it's defined. It's also possible to use the same
PROBE_POINT name where multiple code paths trigger the same action of interest. A probe fires when either path is taken.
You might need to act on a probe only after a loop is run for the number of times specified with this parameter. In such cases, set this GUC to the number of iterations at which point the probe point fires, and reset the counter.
The default value is
1, meaning the probe points always fire when the name matches.
pg2q.probe_sleep milliseconds after hitting the probe point. Then fire the action in
Action to take when the named
pg2q.probe_point is hit. Available actions are:
sleep— Emit a
DEBUGmessage with the probe name.
log— Emit a
LOGmessage with the probe name.
elog(ERROR, ...)to raise an
elog(PANIC, ...), which generally then calls
abort()and delivers a
SIGABRT(signal 6) to cause the backend to core dump. The probe point tries to set the core file limit to enable core dumps if the hard ulimit permits.
sigkill— Deliver the named signal to the backend that hit the probe point.
If nonzero, the probe sleep and action are skipped for backends other than the backend with this ID.
server_2q_version configuration parameters allow the 2ndQuadrant-specific version number and version substring, respectively, to be accessible to external modules.
You can set the table-level option
compress_tuple_target to decide when to trigger compression on a tuple. Previously, you used the
toast_tuple_target (or the compile time default) to decide whether to compress a tuple. However, this was detrimental when a tuple is large enough and has a good compression ratio but not large enough to cross the toast threshold.
Restricts the maximum uncompressed size of the internal representation of any one field that can be written to a table, in bytes.
pg2q.max_tuple_field_size is 1073740799 bytes, which is 1024 bytes less than 1 GiB. This value is slightly less than the 1 GiB maximum field size usually imposed by PostgreSQL. This margin helps prevent cases where tuples are committed to disk but can't then be processed by logical decoding output plugins and sent to downstream servers.
11073741823 to disable the feature.
If your application doesn't rely on inserting large fields, consider setting
pg2q.max_tuple_field_size to a much smaller value, such as 100MB or even less. Among other issues, large fields can:
- Cause surprising application behavior
- Increase memory consumption for the database engine during queries and replication
- Slow down logical replication
While this parameter is enabled, oversized fields cause queries that
UPDATE an oversized field to fail with an
ERROR such as:
Only the superuser can set
pg2q.max_tuple_field_size. You can use a
SECURITY DEFINER function wrapper if you want to allow a non-superuser to set it.
If you change
pg2q.max_tuple_field_size, fields larger than the current
pg2q.max_tuple_field_size that are already on disk don't change. You can
SELECT them as usual. Any
UPDATE that affects tuples with oversized fields fails, even if the oversized field isn't modified, unless the new tuple created by the update operation satisfies the currently active size limits.
DELETE operation doesn't check the field-size limit.
The limit isn't enforced on the text-representation size for I/O of fields because doing so also prevents PostgreSQL from creating and processing temporary in-memory json objects larger than the limit.
The limit isn't enforced for temporary tuples in tuplestores, such as set-returning functions, CTEs, and views. Size checks are deliberately not enforced for any
MATERIALIZED VIEW either.
pg2q.max_tuple_field_size is enforced for
pg_restore. If a
database contains oversized tuples, it does a
pg_dump as usual. However, a
pg_restore fails with the error shown previously. To work around
this issue, restore the dump with
pg2q.max_tuple_field_size overridden in
connection options using
PGOPTIONS or the
string. For example:
Data type specifics:
byteafield, the size used is the decoded binary size. It isn't the text-representation size in hex or octal escape form, that is, the
octet_length()of the field.
bytea_output = 'hex', the maximum size of the I/O representation is
2 * pg2q.max_tuple_field_size + 2bytes.
xmlfield, the measured size is the number of bytes of text in the current database encoding (the
octet_length()of the field), not the number of characters. In UTF-8 encodings, one character usually consumes one byte but might consume six or more bytes for some languages and scripts.
jsonbfield, the measured size is that of the PostgreSQL internal jsonb-encoded datatype representation, the text representation of the json document. In some cases the
jsonbrepresentation for larger json documents is smaller than the text representation. This means that it's possible to insert json documents with text representations larger than any given
pg2q.max_tuple_field_size, although it's uncommon.
Extension-defined data type behavior depends on the implementation of the data type.
The field size used for this limit is the size reported by them
pg_column_size()function, minus the 4 bytes of header PostgreSQL adds to variable-length data types, when used on a literal of the target data type. For example:
For example, to see the computed size of the jsonb field, use:
Due to TOAST compression ,
pg_column_size()often reports smaller values when called on existing on-disk fields. Also, the header for shorter values on disk might be 1 byte instead of 4.
Restricts the maximum size of a single tuple that can be written to a table. This value is the total row width, including the uncompressed width of all potentially compressible or external-storage-capable field values. Field headers count against the size, but fixed row headers don't.
Many PostgreSQL operations, such as logical replication, work on whole rows, as do many applications. You can use this setting to impose a limit on the maximum row size you consider reasonable for your application to prevent inadvertent creation of oversized rows that might pose operational issues.
When applied to an
UPDATE of existing tuples,
pg2q.max_tuple_size isn't enforced as strictly as
pg2q.max_tuple_field_size. It doesn't count the full size of unmodified values in columns with storage other than
pg2q.max_tuple_size is enforced for
pg_restore. See the caveat for