4 ms·
That's true, but why would you want to run pg_dump on the instance? Use pg_receivexlog and friends to have a physical backup and pg_recvlogical for logical back
by ahachete 10y ago
That's true, but why would you want to run pg_dump on the instance? Use pg_receivexlog and friends to have a physical backup and pg_recvlogical for logical backups and you avoid the problem with pg_dump (you're alone with other long-running tx, but it may help).
- koolba 10y agoRegardless of other forms of backups it's useful to have a logical pg_dump based one as well. When shit hits the proverbial fan its nice to have a totally separate backup path that, even if it's not as up to date as a streaming physical backup, can be easily restored. Biggest issues I've heard are either the long running transaction (mitigated a bit by running on a slave), cache busting effect (reading all your data thrashes your OS disk cache), and how painfully long it can take (good luck running pg_dump on a multi TB database). As a backup to a more "live" backup, it's nice to have though. Plus it's dead simple to restore a DB via pg_restore in a lower environment for testing.
- ahachete 10y agoSize does matter. And there are databases which you practically can't backup logically (as you mentioned). So IMHO only applies to small databases in which case, sure, a pg_dump is always handy. But not in the rest of the cases.