Jan Wieck wrote:
>
> ALTER DATABASE BEGIN BACKUP;
>
> Issued by pg_dump before doing anything else.
>
> The command stops ALL other activity in the database, so
> pg_dump has time to pull out at least the information
> about sequences (actually it does this while getting
> tables, might require some changes there so the database
> get's back accessible soon).
>
> ALTER DATABASE ONLINE BACKUP;
>
> Issued by pg_dump when it finished the things that
> require total exclusive database access.
>
> At this time, a logfile switch is done (only if the
> actual database is really logged) and the sequence number
> of the new logfile plus the current datetime remembered.
> The behaviour of pg_dump's backend changes. It will see a
> snapshot of this time (implemented in tqual code) in any
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Note, that I'm implementing multi-version concurrency control
(MVCC) for 6.5: pg_dump will have to run all queries
in one transaction in SERIALIZED mode to get snapshot of
transaction' begin time...
> subsequent command and it is totally unable to do
> anything that would update the database.
>
> Until the final END BACKUP is given, no VACUUM or DROP
> TABLE etc. commands can be run. If they are issued, the
> command will be delayed until pg_dump finished.
Vacuum will not be delete records in which any active
backend is interested - don't worry.
...
>
> All that might look very complicated, but the only commands ^^^^^^^^^^^^^^^^
Yes -:)
We could copy/move pg_dump' stuff into backend...
This way pg_dump will just execute one command
ALTER DATABASE ONLINE BACKUP; -- as I understand
- backend will do all what it need and pg_dump just
write backend' output to a file.
I think that it would be nice to have code in backend to
generate CREATE statements from catalog and extend EXPLAIN
to handle something like EXPLAIN TABLE xxx etc.
We could call EXPLAIN for all \dXXXX in psql and
when dumping schema in pg_dump.
Comments?
Vadim