Jump to:
Avoid use of insecure search_path
settings in pg_dump and other client programs (Noah Misch, Tom Lane)
pg_dump, pg_upgrade, vacuumdb and other PostgreSQL-provided applications were themselves vulnerable to the type of hijacking described in the previous changelog entry; since these applications are commonly run by superusers, they present particularly attractive targets. To make them secure whether or not the installation as a whole has been secured, modify them to include only the pg_catalog
schema in their search_path
settings. Autovacuum worker processes now do the same, as well.
In cases where user-provided functions are indirectly executed by these programs — for example, user-provided functions in index expressions — the tighter search_path
may result in errors, which will need to be corrected by adjusting those user-provided functions to not assume anything about what search path they are invoked under. That has always been good practice, but now it will be necessary for correct behavior. (CVE-2018-1058)
Ensure proper quoting of transition table names when pg_dump emits CREATE TRIGGER ... REFERENCING
commands (Tom Lane)
This oversight could be exploited by an unprivileged user to gain superuser privileges during the next dump/reload or pg_upgrade run. (CVE-2018-16850)
Fix usage of complex connection-string parameters in pg_dump, pg_restore, clusterdb, reindexdb, and vacuumdb (Tom Lane)
The -d
parameter of pg_dump and pg_restore, or the --maintenance-db
parameter of the other programs mentioned, can be a “connection string” containing multiple connection parameters rather than just a database name. In cases where these programs need to initiate additional connections, such as parallel processing or processing of multiple databases, the connection string was forgotten and just the basic connection parameters (database name, host, port, and username) were used for the additional connections. This could lead to connection failures if the connection string included any other essential information, such as non-default SSL or GSS parameters. Worse, the connection might succeed but not be encrypted as intended, or be vulnerable to man-in-the-middle attacks that the intended connection parameters would have prevented. (CVE-2020-25694)
When psql's \connect
command re-uses connection parameters, ensure that all non-overridden parameters from a previous connection string are re-used (Tom Lane)
This avoids cases where reconnection might fail due to omission of relevant parameters, such as non-default SSL or GSS options. Worse, the reconnection might succeed but not be encrypted as intended, or be vulnerable to man-in-the-middle attacks that the intended connection parameters would have prevented. This is largely the same problem as just cited for pg_dump et al, although psql's behavior is more complex since the user may intentionally override some connection parameters. (CVE-2020-25694)
Fix permissions checks in CREATE INDEX
(Nathan Bossart, Noah Misch)
The fix for CVE-2022-1552 caused CREATE INDEX
to apply the table owner's permissions while performing lookups of operator classes and other objects, where formerly the calling user's permissions were used. This broke dump/restore scenarios, because pg_dump issues CREATE INDEX
before re-granting permissions.
Config parameter: | Default value: |
---|---|
default_with_oids | off |
operator_precedence_warning | off |
sql_inheritance | on |
stats_temp_directory | pg_stat_tmp |
wal_keep_segments | 0 |
Config parameter: | Default value in Pg 9.5: | Default value in Pg 15.2: |
---|---|---|
autovacuum_vacuum_cost_delay | 20 | 2 |
checkpoint_completion_target | 0.5 | 0.9 |
extra_float_digits | 0 | 1 |
hot_standby | off | on |
log_autovacuum_min_duration | -1 | 600000 |
log_checkpoints | off | on |
log_directory | pg_log | log |
log_line_prefix | %m [%p] | |
max_replication_slots | 0 | 10 |
max_wal_senders | 0 | 10 |
max_wal_size | 64 | 1024 |
min_wal_size | 5 | 80 |
password_encryption | on | scram-sha-256 |
vacuum_cost_page_miss | 10 | 2 |
wal_level | minimal | replica |
wal_segment_size | 2048 | 16777216 |
⇑ Upgrade to 9.5.1 released on 2016-02-11 - docs
Fix assorted corner-case bugs in pg_dump's processing of extension member objects (Tom Lane)
Fix improper quoting of domain constraint names in pg_dump (Elvis Pranskevichus)
Make pg_dump mark a view's triggers as needing to be processed after its rule, to prevent possible failure during parallel pg_restore (Tom Lane)
⇑ Upgrade to 9.5.3 released on 2016-05-12 - docs
Fix pg_upgrade to correctly restore extension membership for operator families containing only one operator class (Tom Lane)
In such a case, the operator family was restored into the new database, but it was no longer marked as part of the extension. This had no immediate ill effects, but would cause later pg_dump runs to emit output that would cause (harmless) errors on restore.
⇑ Upgrade to 9.5.4 released on 2016-08-11 - docs
In pg_dump with both -c and -C options, avoid emitting an unwanted CREATE SCHEMA public command (David Johnston, Tom Lane)
Improve handling of SIGTERM/control-C in parallel pg_dump and pg_restore (Tom Lane)
Make sure that the worker processes will exit promptly, and also arrange to send query-cancel requests to the connected backends, in case they are doing something long-running such as a CREATE INDEX.
Fix error reporting in parallel pg_dump and pg_restore (Tom Lane)
Previously, errors reported by pg_dump or pg_restore worker processes might never make it to the user's console, because the messages went through the master process, and there were various deadlock scenarios that would prevent the master process from passing on the messages. Instead, just print everything to stderr. In some cases this will result in duplicate messages (for instance, if all the workers report a server shutdown), but that seems better than no message.
Ensure that parallel pg_dump or pg_restore on Windows will shut down properly after an error (Kyotaro Horiguchi)
Previously, it would report the error, but then just sit until manually stopped by the user.
Make parallel pg_dump fail cleanly when run against a standby server (Magnus Hagander)
This usage is not supported unless --no-synchronized-snapshots is specified, but the error was not handled very well.
Make pg_dump behave better when built without zlib support (Kyotaro Horiguchi)
It didn't work right for parallel dumps, and emitted some rather pointless warnings in other cases.
⇑ Upgrade to 9.6 released on 2016-09-29 - docs
Introduce ALTER object DEPENDS ON EXTENSION (Abhijit Menon-Sen)
This command allows a database object to be marked as depending on an extension, so that it will be dropped automatically if the extension is dropped (without needing CASCADE). However, the object is not part of the extension, and thus will be dumped separately by pg_dump.
Add a --strict-names option to pg_dump and pg_restore (Pavel Stehule)
This option causes the program to complain if there is no match for a -t or -n option, rather than silently doing nothing.
In pg_dump, dump locally-made changes of privilege assignments for system objects (Stephen Frost)
While it has always been possible for a superuser to change the privilege assignments for built-in or extension-created objects, such changes were formerly lost in a dump and reload. Now, pg_dump recognizes and dumps such changes. (This works only when dumping from a 9.6 or later server, however.)
Allow pg_dump to dump non-extension-owned objects that are within an extension-owned schema (Martín Marqués)
Previously such objects were ignored because they were mistakenly assumed to belong to the extension owning their schema.
In pg_dump output, include the table name in object tags for object types that are only uniquely named per-table (for example, triggers) (Peter Eisentraut)
Add pg_init_privs system catalog to hold original privileges of initdb-created and extension-created objects (Stephen Frost)
This infrastructure allows pg_dump to dump changes that an installation may have made in privileges attached to system objects. Formerly, such changes would be lost in a dump and reload, but now they are preserved.
⇑ Upgrade to 9.6.1 released on 2016-10-27 - docs
Fix pg_dump to work against pre-7.4 servers (Amit Langote, Tom Lane)
⇑ Upgrade to 9.6.2 released on 2017-02-09 - docs
Fix tracking of initial privileges for extension member objects so that it works correctly with ALTER EXTENSION ... ADD/DROP (Stephen Frost)
An object's current privileges at the time it is added to the extension will now be considered its default privileges; only later changes in its privileges will be dumped by subsequent pg_dump runs.
Fix pg_dump to emit the data of a sequence that is marked as an extension configuration table (Michael Paquier)
Fix mishandling of ALTER DEFAULT PRIVILEGES ... REVOKE in pg_dump (Stephen Frost)
pg_dump missed issuing the required REVOKE commands in cases where ALTER DEFAULT PRIVILEGES had been used to reduce privileges to less than they would normally be.
Fix pg_dump to dump user-defined casts and transforms that use built-in functions (Stephen Frost)
Fix pg_restore with --create --if-exists to behave more sanely if an archive contains unrecognized DROP commands (Tom Lane)
This doesn't fix any live bug, but it may improve the behavior in future if pg_restore is used with an archive generated by a later pg_dump version.
⇑ Upgrade to 9.6.3 released on 2017-05-11 - docs
Fix pg_dump/pg_restore to correctly handle privileges for the public schema when using --clean option (Stephen Frost)
Other schemas start out with no privileges granted, but public does not; this requires special-case treatment when it is dropped and restored due to the --clean option.
In pg_dump, fix incorrect schema and owner marking for comments and security labels of some types of database objects (Giuseppe Broccolo, Tom Lane)
In simple cases this caused no ill effects; but for example, a schema-selective restore might omit comments it should include, because they were not marked as belonging to the schema of their associated object.
Fix typo in pg_dump's query for initial privileges of a procedural language (Peter Eisentraut)
This resulted in pg_dump always believing that the language had no initial privileges. Since that's true for most procedural languages, ill effects from this bug are probably rare.
⇑ Upgrade to 9.6.4 released on 2017-08-10 - docs
Fix pg_dump and pg_restore to emit REFRESH MATERIALIZED VIEW commands last (Tom Lane)
This prevents errors during dump/restore when a materialized view refers to tables owned by a different user.
Improve pg_dump/pg_restore's reporting of error conditions originating in zlib (Vladimir Kunschikov, Álvaro Herrera)
Fix pg_dump with the --clean option to drop event triggers as expected (Tom Lane)
It also now correctly assigns ownership of event triggers; before, they were restored as being owned by the superuser running the restore script.
Fix pg_dump with the --clean option to not fail when the public schema doesn't exist (Stephen Frost)
Fix pg_dump to not emit invalid SQL for an empty operator class (Daniel Gustafsson)
Fix pg_dump output to stdout on Windows (Kuntal Ghosh)
A compressed plain-text dump written to stdout would contain corrupt data due to failure to put the file descriptor into binary mode.
Fix pg_get_ruledef()
to print correct output for the ON SELECT rule of a view whose columns have been renamed (Tom Lane)
In some corner cases, pg_dump relies on pg_get_ruledef()
to dump views, so that this error could result in dump/reload failures.
⇑ Upgrade to 10 released on 2017-10-05 - docs
Remove pg_dump/pg_dumpall support for dumping from pre-8.0 servers (Tom Lane)
Users needing to dump from pre-8.0 servers will need to use dump programs from PostgreSQL 9.6 or earlier. The resulting output should still load successfully into newer servers.
Add --no-blobs
option to pg_dump (Guillaume Lelarge)
This suppresses dumping of large objects.
Issue fsync()
on the output files generated by pg_dump and pg_dumpall (Michael Paquier)
This provides more security that the output is safely stored on disk before the program exits. This can be disabled with the new --no-sync
option.
⇑ Upgrade to 10.1 released on 2017-11-09 - docs
Fix insufficient schema-qualification in some new queries in pg_dump and psql (Vitaly Burovoy, Tom Lane, Noah Misch)
⇑ Upgrade to 10.2 released on 2018-02-08 - docs
Fix pg_dump to make ACL (permissions), comment, and security label entries reliably identifiable in archive output formats (Tom Lane)
The “tag” portion of an ACL archive entry was usually just the name of the associated object. Make it start with the object type instead, bringing ACLs into line with the convention already used for comment and security label archive entries. Also, fix the comment and security label entries for the whole database, if present, to make their tags start with DATABASE
so that they also follow this convention. This prevents false matches in code that tries to identify large-object-related entries by seeing if the tag starts with LARGE OBJECT
. That could have resulted in misclassifying entries as data rather than schema, with undesirable results in a schema-only or data-only dump.
Note that this change has user-visible results in the output of pg_restore --list
.
⇑ Upgrade to 10.3 released on 2018-03-01 - docs
Avoid use of insecure search_path
settings in pg_dump and other client programs (Noah Misch, Tom Lane)
pg_dump, pg_upgrade, vacuumdb and other PostgreSQL-provided applications were themselves vulnerable to the type of hijacking described in the previous changelog entry; since these applications are commonly run by superusers, they present particularly attractive targets. To make them secure whether or not the installation as a whole has been secured, modify them to include only the pg_catalog
schema in their search_path
settings. Autovacuum worker processes now do the same, as well.
In cases where user-provided functions are indirectly executed by these programs — for example, user-provided functions in index expressions — the tighter search_path
may result in errors, which will need to be corrected by adjusting those user-provided functions to not assume anything about what search path they are invoked under. That has always been good practice, but now it will be necessary for correct behavior. (CVE-2018-1058)
Fix incorrect pg_dump output for some non-default sequence limit values (Alexey Bashtanov)
Fix pg_dump's mishandling of STATISTICS
objects (Tom Lane)
An extended statistics object's schema was mislabeled in the dump's table of contents, possibly leading to the wrong results in a schema-selective restore. Its ownership was not correctly restored, either. Also, change the logic so that statistics objects are dumped/restored, or not, as independent objects rather than tying them to the dump/restore decision for the table they are on. The original definition could not scale to the planned future extension to cross-table statistics.
⇑ Upgrade to 10.4 released on 2018-05-10 - docs
Accept TRUE
and FALSE
as partition bound values (Amit Langote)
Previously, only string-literal values were accepted for a boolean partitioning column. But then pg_dump would print such values as TRUE
or FALSE
, leading to dump/reload failures.
Fix mis-quoting of values for list-valued GUC variables in dumps (Michael Paquier, Tom Lane)
The local_preload_libraries
, session_preload_libraries
, shared_preload_libraries
, and temp_tablespaces
variables were not correctly quoted in pg_dump output. This would cause problems if settings for these variables appeared in CREATE FUNCTION ... SET
or ALTER DATABASE/ROLE ... SET
clauses.
⇑ Upgrade to 10.5 released on 2018-08-09 - docs
Further fix mis-quoting of values for list-valued GUC variables in dumps (Tom Lane)
The previous fix for quoting of search_path
and other list-valued variables in pg_dump output turned out to misbehave for empty-string list elements, and it risked truncation of long file paths.
Fix pg_dump's failure to dump REPLICA IDENTITY
properties for constraint indexes (Tom Lane)
Manually created unique indexes were properly marked, but not those created by declaring UNIQUE
or PRIMARY KEY
constraints.
⇑ Upgrade to 11 released on 2018-10-18 - docs
Make pg_dump dump the properties of a database, not just its contents (Haribabu Kommi)
Previously, attributes of the database itself, such as database-level GRANT
/REVOKE
permissions and ALTER DATABASE SET
variable settings, were only dumped by pg_dumpall. Now pg_dump --create
and pg_restore --create
will restore these database properties in addition to the objects within the database. pg_dumpall -g
now only dumps role- and tablespace-related attributes. pg_dumpall's complete output (without -g
) is unchanged.
pg_dump and pg_restore, without --create
, no longer dump/restore database-level comments and security labels; those are now treated as properties of the database.
pg_dumpall's output script will now always create databases with their original locale and encoding, and hence will fail if the locale or encoding name is unknown to the destination system. Previously, CREATE DATABASE
would be emitted without these specifications if the database locale and encoding matched the old cluster's defaults.
pg_dumpall --clean
now restores the original locale and encoding settings of the postgres
and template1
databases, as well as those of user-created databases.
Add pg_dumpall option --encoding
to control output encoding (Michael Paquier)
pg_dump already had this option.
Add pg_dump option --load-via-partition-root
to force loading of data into the partition's root table, rather than the original partition (Rushabh Lathia)
This is useful if the system to be loaded to has different collation definitions or endianness, possibly requiring rows to be stored in different partitions than previously.
Add an option to suppress dumping and restoring database object comments (Robins Tharakan)
The new pg_dump, pg_dumpall, and pg_restore option is --no-comments
.
⇑ Upgrade to 11.1 released on 2018-11-08 - docs
Ensure proper quoting of transition table names when pg_dump emits CREATE TRIGGER ... REFERENCING
commands (Tom Lane)
This oversight could be exploited by an unprivileged user to gain superuser privileges during the next dump/reload or pg_upgrade run. (CVE-2018-16850)
⇑ Upgrade to 11.2 released on 2019-02-14 - docs
Fix pg_dump's handling of materialized views with indirect dependencies on primary keys (Tom Lane)
This led to mis-labeling of such views' dump archive entries, causing harmless warnings about “archive items not in correct section order”; less harmlessly, selective-restore options depending on those labels, such as --section
, might misbehave.
Make pg_dump include ALTER INDEX SET STATISTICS
commands (Michael Paquier)
When the ability to attach statistics targets to index expressions was added, we forgot to teach pg_dump about it, so that such settings were lost in dump/reload.
Fix pg_dump's dumping of tables that have OIDs (Peter Eisentraut)
The WITH OIDS
clause was omitted if it needed to be applied to the first table to be dumped.
Avoid null-pointer-dereference crash on some platforms when pg_dump or pg_restore tries to report an error (Tom Lane)
⇑ Upgrade to 11.3 released on 2019-05-09 - docs
Accept XML documents as valid values of type xml
when xmloption
is set to content
, as required by SQL:2006 and later (Chapman Flack)
Previously PostgreSQL followed the SQL:2003 definition, which doesn't allow this. But that creates a serious problem for dump/restore: there is no setting of xmloption
that will accept all valid XML data. Hence, switch to the 2006 definition.
pg_dump is also modified to emit SET xmloption = content
while restoring data, ensuring that dump/restore works even if the prevailing setting is document
.
⇑ Upgrade to 11.4 released on 2019-06-20 - docs
Fix ordering of GRANT
commands emitted by pg_dump and pg_dumpall for databases and tablespaces (Nathan Bossart, Michael Paquier)
If cascading grants had been issued, restore might fail due to the GRANT
commands being given in an order that didn't respect their interdependencies.
Make pg_dump recreate table partitions using CREATE TABLE
then ATTACH PARTITION
, rather than including PARTITION OF
in the creation command (Álvaro Herrera, David Rowley)
This avoids problems with the partition's column order possibly being changed to match the parent's. Also, a partition is now restorable from the dump (as a standalone table) even if its parent table isn't restored; the ATTACH
will fail, but that can just be ignored.
⇑ Upgrade to 11.5 released on 2019-08-08 - docs
Fix pg_dump to ensure that custom operator classes are dumped in the right order (Tom Lane)
If a user-defined opclass is the subtype opclass of a user-defined range type, related objects were dumped in the wrong order, producing an unrestorable dump. (The underlying failure to handle opclass dependencies might manifest in other cases too, but this is the only known case.)
⇑ Upgrade to 12 released on 2019-10-03 - docs
When pg_dump emits data with INSERT
commands rather than COPY
, allow more than one data row to be included in each INSERT
(Surafel Temesgen, David Rowley)
The option controlling this is --rows-per-insert
.
Allow pg_dump to emit INSERT ... ON CONFLICT DO NOTHING
(Surafel Temesgen)
This avoids conflict failures during restore. The option is --on-conflict-do-nothing
.
Decouple the order of operations in a parallel pg_dump from the order used by a subsequent parallel pg_restore (Tom Lane)
This allows pg_restore to perform more-fully-parallelized parallel restores, especially in cases where the original dump was not done in parallel. Scheduling of a parallel pg_dump is also somewhat improved.
Allow the extra_float_digits setting to be specified for pg_dump and pg_dumpall (Andrew Dunstan)
This is primarily useful for making dumps that are exactly comparable across different source server versions. It is not recommended for normal use, as it may result in loss of precision when the dump is restored.
⇑ Upgrade to 12.1 released on 2019-11-14 - docs
Fix scheduling of parallel restore of a foreign key constraint on a partitioned table (Álvaro Herrera)
pg_dump failed to emit full dependency information for partitioned tables' foreign keys. This could allow parallel pg_restore to try to recreate a foreign key constraint too soon.
In pg_dump, ensure stable output order for similarly-named triggers and row-level-security policy objects (Benjie Gillam)
Previously, if two triggers on different tables had the same names, they would be sorted in OID-based order, which is less desirable than sorting them by table name. Likewise for RLS policies.
⇑ Upgrade to 12.2 released on 2020-02-13 - docs
Fix parallel pg_dump/pg_restore to more gracefully handle failure to create worker processes (Tom Lane)
Prevent possible crash or lockup when attempting to terminate a parallel pg_dump/pg_restore run via a signal (Tom Lane)
⇑ Upgrade to 12.3 released on 2020-05-14 - docs
Add pg_dump support for ALTER ... DEPENDS ON EXTENSION
(Álvaro Herrera)
pg_dump previously ignored dependencies added this way, causing them to be forgotten during dump/restore or pg_upgrade.
Fix pg_dump to dump comments on RLS policy objects (Tom Lane)
In pg_dump, postpone restore of event triggers till the end (Fabrízio de Royes Mello, Hamid Akhtar, Tom Lane)
This minimizes the risk that an event trigger could interfere with the restoration of other objects.
⇑ Upgrade to 12.4 released on 2020-08-13 - docs
Report out-of-disk-space errors properly in pg_dump and pg_basebackup (Justin Pryzby, Tom Lane, Álvaro Herrera)
Some code paths could produce silly reports like “could not write file: Success”.
Make pg_restore cope with data-offset-less custom-format archive files when it needs to restore data items out of order (David Gilman, Tom Lane)
pg_dump will produce such files if it cannot seek its output (for example, if the output is piped to something). This fix primarily improves the ability to do a parallel restore from such a file.
Fix parallel restore of tables having both table-level privileges and per-column privileges (Tom Lane)
The table-level privilege grants have to be applied first, but a parallel restore did not reliably order them that way; this could lead to “tuple concurrently updated” errors, or to disappearance of some per-column privilege grants. The fix for this is to include dependency links between such entries in the archive file, meaning that a new dump has to be taken with a corrected pg_dump to ensure that the problem will not recur.
⇑ Upgrade to 13 released on 2020-09-24 - docs
Add pg_dump option --include-foreign-data
to dump data from foreign servers (Luis Carril)
⇑ Upgrade to 13.1 released on 2020-11-12 - docs
Fix usage of complex connection-string parameters in pg_dump, pg_restore, clusterdb, reindexdb, and vacuumdb (Tom Lane)
The -d
parameter of pg_dump and pg_restore, or the --maintenance-db
parameter of the other programs mentioned, can be a “connection string” containing multiple connection parameters rather than just a database name. In cases where these programs need to initiate additional connections, such as parallel processing or processing of multiple databases, the connection string was forgotten and just the basic connection parameters (database name, host, port, and username) were used for the additional connections. This could lead to connection failures if the connection string included any other essential information, such as non-default SSL or GSS parameters. Worse, the connection might succeed but not be encrypted as intended, or be vulnerable to man-in-the-middle attacks that the intended connection parameters would have prevented. (CVE-2020-25694)
When psql's \connect
command re-uses connection parameters, ensure that all non-overridden parameters from a previous connection string are re-used (Tom Lane)
This avoids cases where reconnection might fail due to omission of relevant parameters, such as non-default SSL or GSS options. Worse, the reconnection might succeed but not be encrypted as intended, or be vulnerable to man-in-the-middle attacks that the intended connection parameters would have prevented. This is largely the same problem as just cited for pg_dump et al, although psql's behavior is more complex since the user may intentionally override some connection parameters. (CVE-2020-25694)
Ensure that pg_dump collects per-column information about extension configuration tables (Fabrízio de Royes Mello, Tom Lane)
Failure to do this led to crashes when specifying --inserts
, or underspecified (though usually correct) COPY
commands when using COPY
to reload the tables' data.
⇑ Upgrade to 13.2 released on 2021-02-11 - docs
Fix pg_dump's dumping of inherited generated columns (Peter Eisentraut)
The previous behavior resulted in (harmless) errors during restore.
In pg_dump, ensure that the restore script runs ALTER PUBLICATION ADD TABLE
commands as the owner of the publication, and similarly runs ALTER INDEX ATTACH PARTITION
commands as the owner of the partitioned index (Tom Lane)
Previously, these commands would be run by the role that started the restore script; which will usually work, but in corner cases that role might not have adequate permissions.
Fix pg_dump to handle WITH GRANT OPTION
in an extension's initial privileges (Noah Misch)
If an extension's script creates an object and grants privileges on it with grant option, then later the user revokes such privileges, pg_dump would generate incorrect SQL for reproducing the situation. (Few if any extensions do this today.)
⇑ Upgrade to 13.3 released on 2021-05-13 - docs
Fix pg_dump's dumping of generated columns in partitioned tables (Peter Eisentraut)
A fix introduced in the previous minor release should not be applied to partitioned tables, only traditionally-inherited tables.
⇑ Upgrade to 13.4 released on 2021-08-12 - docs
Fix pg_dump to correctly handle triggers on partitioned tables whose enabled status is different from their parent triggers' status (Justin Pryzby, Álvaro Herrera)
⇑ Upgrade to 14 released on 2021-09-30 - docs
Remove support for postfix (right-unary) operators (Mark Dilger)
pg_dump and pg_upgrade will warn if postfix operators are being dumped.
Allow pg_dump to dump only certain extensions (Guillaume Lelarge)
This is controlled by option --extension
.
Allow multiple verbose option specifications (-v
) to increase the logging verbosity (Tom Lane)
This behavior is supported by pg_dump, pg_dumpall, and pg_restore.
⇑ Upgrade to 14.1 released on 2021-11-11 - docs
Fix pg_dump to dump non-global default privileges correctly (Neil Chen, Masahiko Sawada)
If a global (unrestricted) ALTER DEFAULT PRIVILEGES
command revoked some present-by-default privilege, for example EXECUTE
for functions, and then a restricted ALTER DEFAULT PRIVILEGES
command granted that privilege again for a selected role or schema, pg_dump failed to dump the restricted privilege grant correctly.
Make pg_dump acquire shared lock on partitioned tables that are to be dumped (Tom Lane)
This oversight was usually pretty harmless, since once pg_dump has locked any of the leaf partitions, that would suffice to prevent significant DDL on the partitioned table itself. However problems could ensue when dumping a childless partitioned table, since no relevant lock would be held.
Fix crash in pg_dump when attempting to dump trigger definitions from a pre-8.3 server (Tom Lane)
⇑ Upgrade to 14.2 released on 2022-02-10 - docs
Fix pg_dump's dump ordering for user-defined casts (Tom Lane)
In rare cases, the output script might refer to a user-defined cast before it had been created.
Fix pg_dump's --inserts
and --column-inserts
modes to handle tables containing both generated columns and dropped columns (Tom Lane)
Fix possible mis-reporting of errors in pg_dump and pg_basebackup (Tom Lane)
The previous code failed to check for errors from some kernel calls, and could report the wrong errno values in other cases.
⇑ Upgrade to 14.3 released on 2022-05-12 - docs
Re-allow database
.schema
.table
patterns in psql, pg_dump, and pg_amcheck (Mark Dilger)
Versions before v14 silently ignored all but the schema
and table
fragments of a pattern containing more than one dot. Refactoring in v14 accidentally broke that use-case. Reinstate it, but now complain if the first fragment is not the name of the current database.
⇑ Upgrade to 14.5 released on 2022-08-11 - docs
Fix permissions checks in CREATE INDEX
(Nathan Bossart, Noah Misch)
The fix for CVE-2022-1552 caused CREATE INDEX
to apply the table owner's permissions while performing lookups of operator classes and other objects, where formerly the calling user's permissions were used. This broke dump/restore scenarios, because pg_dump issues CREATE INDEX
before re-granting permissions.
⇑ Upgrade to 15 released on 2022-10-13 - docs
Remove pg_dump's --no-synchronized-snapshots
option (Tom Lane)
All still-supported server versions support synchronized snapshots, so there's no longer a need for this option.
Make pg_dump dump public
schema ownership changes and security labels (Noah Misch)
Improve parallel pg_dump's performance for tables with large TOAST tables (Tom Lane)
Limit support of pg_dump and pg_dumpall to servers running PostgreSQL 9.2 or later (Tom Lane)
⇑ Upgrade to 15.1 released on 2022-11-10 - docs
Fix pg_dump's failure to dump comments attached to some CHECK
constraints (Tom Lane)
⇑ Upgrade to 15.2 released on 2023-02-09 - docs
Allow REPLICA IDENTITY
to be set on an index that's not (yet) valid (Tom Lane)
When pg_dump dumps a partitioned index that's marked REPLICA IDENTITY
, it generates a command sequence that applies REPLICA IDENTITY
before the partitioned index has been marked valid, causing restore to fail. There seems no very good reason to prohibit doing it in that order, so allow it. The marking will have no effect anyway until the index becomes valid.
Avoid harmless warning from pg_dump in --if-exists
mode (Tom Lane)
If the public
schema has a non-default owner then use of pg_dump's --if-exists
option resulted in a warning message “warning: could not find where to insert IF EXISTS in statement "-- *not* dropping schema, since initdb creates it"”. The dump output was okay, though.