# pg\_dump Published articles for pg\_dump. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Waiting for PostgreSQL 19 - new pg\_get\_\*\_ddl() functions DevFeed: [Waiting for PostgreSQL 19 - new pg\_get\_\*\_ddl() functions]() Original publisher: [Read original article]() Author: depesz Published: 2026-04-09T16:37:45Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [SQL](), [Databases]() Tags: [functions](), [pg-dump](), [pg-get-database-ddl](), [pg-get-role-ddl](), [pg-get-tablespace-ddl](), [pg19](), [postgresql](), [schema](), [sql](), [uncategorized](), [waiting]() ### AI overview This article examines proposed PostgreSQL 19 SQL-callable pg_get_*_ddl() functions that generate DDL for recreating databases, roles, and tablespaces. It demonstrates their output and options, notes that role passwords are not exported, and observes that support for additional object types is still missing. ### Source excerpt On 5th of April 2026, Andrew Dunstan committed patch: Add pg_get_database_ddl() function Add a new SQL-callable function that returns the DDL statements needed to recreate a database. It takes a regdatabase argument and an optional VARIADIC text argument for options that are specified as alternating name/value pairs. The following options are supported: pretty (boolean) ... Continue reading "Waiting for PostgreSQL 19 - new pg_get_*_ddl() functions" ## Waiting for PostgreSQL 19 - Add non-text output formats to pg\_dumpall DevFeed: [Waiting for PostgreSQL 19 - Add non-text output formats to pg\_dumpall]() Original publisher: [Read original article]() Author: depesz Published: 2026-03-17T10:29:38Z Content type: article Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [backups](), [Databases]() Tags: [backup](), [backups](), [compression](), [maintenance](), [pg-dump](), [pg-dumpall](), [pg19](), [postgresql](), [uncategorized](), [waiting]() ### AI overview The article examines a PostgreSQL 19 patch that adds custom, directory, and tar output formats to pg_dumpall. It describes the resulting files and explains how the formats can support more selective restoration and simpler backups. ### Source excerpt On 26th of February 2026, Andrew Dunstan committed patch: Add non-text output formats to pg_dumpall pg_dumpall can now produce output in custom, directory, or tar formats in addition to plain text SQL scripts. When using non-text formats, pg_dumpall creates a directory containing: - toc.glo: global data (roles and tablespaces) in custom format - map.dat: ... Continue reading "Waiting for PostgreSQL 19 - Add non-text output formats to pg_dumpall" ## Why pg\_dump Is Useful for PostgreSQL Data Migration and Troubleshooting DevFeed: [Why pg\_dump Is Useful for PostgreSQL Data Migration and Troubleshooting]() Original publisher: [Read original article]() Author: Robert Haas (noreply@blogger.com) Published: 2024-11-01T15:56:00Z Content type: opinion Language: en Sources: [Robert Haas]() Topics: [PostgreSQL](), [postgresql clusters](), [Databases](), [cpu](), [floating-point]() Tags: [backup](), [backups](), [cpu](), [database](), [floating-point](), [pg-dump](), [postgresql](), [sql](), [version]() ### AI overview The article explains why pg_dump is useful beyond full-cluster backups. Its human-readable SQL output can support database migration, major-version changes, CPU architecture changes, and troubleshooting, although it may require manual modification and can incur performance costs or fail in some cases. ### Source excerpt I wrote a blog post a couple of weeks ago entitled Is pg_dump a Backup Tool?. In that post, I argued in the affirmative, but also said that it's probably shouldn't be your primary backup mechanism. For that, you probably shouldn't directly use anything that is included in PostgreSQL itself, but rather a well-maintained third-party backup tool such as barman or pgbackrest. But today, I want to talk a little more about why I believe that pg_dump is both amazingly useful for solving all kinds of PostgreSQL-related problems and also just a great piece of technology. Read more " ## Is pg\_dump a Backup Tool? DevFeed: [Is pg\_dump a Backup Tool?]() Original publisher: [Read original article]() Author: Robert Haas (noreply@blogger.com) Published: 2024-10-15T20:03:00Z Content type: opinion Language: en Sources: [Robert Haas]() Topics: [PostgreSQL](), [Databases](), [configuration]() Tags: [backup](), [backups](), [configuration](), [database](), [pg-dump](), [pg-dumpall](), [postgresql]() ### AI overview The article argues that pg_dump and pg_dumpall can function as backup tools because they can save database data and restore it later. It also explains that this approach may be unsuitable for large databases due to slow backups and restores, possible database bloat, version-related restore errors, and the need to separately preserve globals and configuration files. ### Source excerpt Recently, I've been hearing a lot of experienced PostgreSQL users reiterate this line: "pg_dump is not a backup tool." In fact, the documentation has recently been updated to avoid saying that it is a backup tool, to widespread relief. Experienced PostgreSQL users and developers have been publicly called out for having the temerity to assert that pg_dump is, in fact, a backup tool. I find this narrative deeply frustrating, for two reasons.Read more " ## PostgreSQL Concurrency: Isolation and Locking DevFeed: [PostgreSQL Concurrency: Isolation and Locking]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2018-07-03T11:30:13Z Content type: tutorial Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Concurrency](), [consistency](), [Transactions](), [acid]() Tags: [acid](), [concurrency](), [consistency](), [locking](), [pg-dump](), [postgresql](), [transactions]() ### AI overview This primer explains PostgreSQL isolation and locking as mechanisms for handling concurrent access while maintaining consistency. It discusses ACID-compliant transactions, isolation levels, locking control, and the snapshot behavior used by pg_dump for backups. ### Source excerpt PostgreSQL is a relational database management system. It's even the world's most advanced open source one of them. As such, as its core, Postgres solves concurrent access to a set of data and maintains consistency while allowing concurrent operations. This article is a primer on PostgreSQL Isolation and Locking properties and behaviors. You might be interested into the previous article in the series: PostgreSQL Concurrency: Data Modification Language. ## Postgres backups: Logical vs. Physical an overview DevFeed: [Postgres backups: Logical vs. Physical an overview]() Original publisher: [Read original article]() Author: Map Published: 2017-09-03T20:55:56Z Content type: tutorial Language: en Sources: [Craig Kerstiens]() Topics: [backups](), [Database](), [Databases](), [data]() Tags: [backing-up](), [backup](), [backups](), [checksums](), [dump](), [environments](), [logical](), [overview](), [pg-dump](), [portable](), [postgres](), [postgresql](), [production](), [sql](), [wal]() ### AI overview This article explains PostgreSQL's two backup types: logical backups, which are portable and can target selected tables but add database load, and physical backups, which consist of the database's bytes on disk. It also discusses checksums, corruption detection, and the role of the write-ahead log. ### Source excerpt It's not a very disputed topic that you should backup your database, and further test your backups. What is a little less discussed, at least for Postgres, is the types of backups that exist. Within Postgres there are two forms of backups and understanding them is a useful foundation for anyone working with Postgres. The two backup types are Physical: which consist of the actual bytes on disk, Logical: which is a more portable format. Let's dig into each a bit more so you can better assess which makes sense for you. Logical backups Logical backups are the most well known type within Postgres. This is what you get when you run pg_dump against a database. There are a number of different formats you can get from logical backups and Postgres does a good job of making it easy to compress and configure this backup how you see fit. When a logical backup is run against a database it is not throttled, this introduces a noticable load on your database. As it's reading the data from disk and generating (in layman terms) a bunch of SQL INSERT statements, it has to actually see the data. It's of note that older Postgres databases (read: prior to 9.3) there were no checksums against your database. Checksums are just one tool for you to help check against data corruption. Because a logical dump has to actually read and generate the data to insert it will discover any corruption that exists for you. This portable format is also very useful to pull down copies from production to different environments. I.e. if you need a copy of production data down on your local laptop pg_dump is the way to do it. Logical backups are also database specific, but then allow you to dump only certain tables. All in all logical backups bring some good features, but come at two cost: Load on your system The backup contains data as of the time when it ran Physical backups Physical backups are another option when it comes to backing up your database. As we mentioned earlier it is the physical bytes on disk ## pg\_restore -L & pg\_staging DevFeed: [pg\_restore -L & pg\_staging]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2011-08-29T16:05:00Z Content type: tutorial Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Database](), [configuration]() Tags: [configuration](), [pg-dump](), [postgresql](), [sql]() ### AI overview This tutorial explains how to use pg_restore list files and the pg_staging tool to selectively restore objects from PostgreSQL custom-format dumps. It covers editing restore lists to exclude tables, schemas, data, triggers, and related functions. ### Source excerpt On the PostgreSQL Hackers mailing lists, Andrew Dunstan just proposed some new options for pg_dump and pg_restore to ease our lives. One of the answers was talking about some scripts available to exploit the pg_restore listing that you play with using options -l and -L, or the long name versions --list and --use-list. The pg_staging tool allows you to easily exploit those lists too. The pg_restore list is just a listing of one object per line of all objects contained into a custom dump, that is one made with pg_dump -Fc. You can then tweak this listing in order to comment out some objects (prepending a ; to the line where you find it), and give your hacked file back to pg_restore --use-list so that it will skip them. ## pg\_staging PostgreSQL backup restoration tool enters Debian's NEW queue DevFeed: [pg\_staging PostgreSQL backup restoration tool enters Debian's NEW queue]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2009-11-25T10:49:00Z Content type: release Language: en Sources: [Dimitri Fontaine]() Topics: [PostgreSQL](), [Tool](), [backups](), [Databases](), [Debian]() Tags: [backups](), [commands](), [databases](), [debian](), [pg-dump](), [postgresql](), [release](), [server](), [snapshot](), [staging]() ### AI overview The article introduces pg_staging, a PostgreSQL tool entering Debian's NEW queue. It provides commands for dumping and restoring databases and supports creating staging environments from backups for backup validation, development, integration, pre-live testing, and snapshots. ### Source excerpt So there it is, this newer contribution of mine that I presented at PGDay is now in debian NEW queue. pg_staging will empower you with respect to what you do about those nightly backups ( pg_dump -Fc or something). The tool provides a lot of commands to either dump or restore a database. It comes with documentation covering about it all, except for the londiste support part, which will be there in time for 1.0.0 release. The Todo list is getting smaller and smaller, the version you'll soon find in debian sid is already called 0.9.