Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It only takes a minute to sign up.
pg_dump starts a transaction, similarly to how any other long running query will work. The consistency guarantees there come from the MVCC implementation. The dump will always be self-consistent within those rules.
All the fuzzy parts of MVCC are around around things like what order UPDATE transactions become visible to other clients and how the locks are acquired. pg_dump is strict about the ordering and acquires a read lock on the whole database to dump it. For most people, that's what they expect, and the mechanism used never causes any trouble. The main concurrency risk is that clients trying to change the database structure will be blocked while the dump is running. That doesn't impact the quality of the dump though.
First sorry for answering on this old thread. But from my experience I can not confirm the statement that you can trust pg_dump/
I switched some month ago for a project to postgres. And of course I made all backups with pg_dump from the live system as suggested. But after the first backup check I figured out that all dumps having different sizes. After restoring random some of them, I figured out that some tables are missing. So I started to analyze why this is happen and I figured out that if the overlaying application, e.g. app servers, locking some tables and pg_dump is not waiting until they are released. I was needed every time to stop the server for the backup period which is not a good solution.
So I still looking for a fix but as I said I tottally disagree with the statement that you can trust pg_dump.