Обсуждение: pg_dumpall forces plain text format

I was trying to do a data+lo dump using pg_dumpall:

pg_dumpall -C -a -b -o -Ft > dumptest.data

Unfortunately I kept getting this error:

pg_dump: large object output is not supported for plain text dump files.
pg_dump: (Use a different output format.)

Upon looking at the pg_dumpall shell script I found out why:

PGDUMP="${PGPATH}/pg_dump $connectopts $pgdumpextraopts -Fp"

Is there a particular reason why plain text is forced?  Could this be removed
in the next version?  Or even moved to a pg_dumpall command line option?  I
really dislike using nonstandard tools.

Regards,
Andrew

Andrew Kohlsmith <akohlsmith@mixdown.org> writes:
> Is there a particular reason why plain text is forced?

Because pg_dumpall is producing a script file.

This is obviously not optimal, but it's not very clear how to do better.

            regards, tom lane

Andrew Kohlsmith <akohlsmith@mixdown.org> writes:
> Is there a way to start a transaction at the start of
> the dump and hold it throughout successive connections, finally releasing it
> at the end?

No, and since one backend can only talk to one database, I don't foresee
that changing.

> Or is that on the TODO for whenever foreign keys can be across databases?

I very seriously doubt that PG will *ever* support foreign keys across
databases.

The current development direction is not to improve communication across
databases, but to support schemas and improve privilege checking so that
users can more usefully be assigned separate schemas within a single
database.  I think that multiple databases in a cluster will eventually
be used only for the cases where you *want* airtight separation between
two collections of data.

Hence, I'm not particularly concerned by complaints about lack of
cross-database functionality --- the folks who think they want that
actually want cross-schema operations, which will work fine in 7.3.

            regards, tom lane

You could fake some of this (select only) by using the dblink stuff in
contrib.....  You could link back to yourself and make it work.  Maybe if
you REALLY need it, you could modify dblink to allow updates as well as
selects.  If you really need it that bad, you have the source, write it.

grant wrote:
> You could fake some of this (select only) by using the dblink stuff in
> contrib.....  You could link back to yourself and make it work.  Maybe if
> you REALLY need it, you could modify dblink to allow updates as well as
> selects.  If you really need it that bad, you have the source, write it.

dblink in cvs will work on 7.2.x and supports UPDATE/INSERT/DELETE.

Joe

> > Is there a particular reason why plain text is forced?
> Because pg_dumpall is producing a script file.
> This is obviously not optimal, but it's not very clear how to do better.

Agreed.  :-)

I notice that pg_dumpall just uses a query to grab a list of databases and
some information about them and then cycles through them and runs pg_dump for
each one to dump it.  I could easily do this myself but that would mean that
both pg_dumpall and whatever method I come up with do not guarantee
referential integrity across databases (I'm specifically thinking about
foreign keys).

Now IIRC, Postgres doesn't allow foreign keys across databases so this point
is moot at this time.  Is there a way to start a transaction at the start of
the dump and hold it throughout successive connections, finally releasing it
at the end?  Or is that on the TODO for whenever foreign keys can be across
databases?

Regards,
Andrew

> > Or is that on the TODO for whenever foreign keys can be across databases?
> I very seriously doubt that PG will *ever* support foreign keys across
> databases.

No problem.  I'm not that advanced of a user or admin to want it, I was just
trying to peer into the crystal ball and try to anticipate future problems.
:-)

> The current development direction is not to improve communication across
> databases, but to support schemas and improve privilege checking so that
> users can more usefully be assigned separate schemas within a single
> database.  I think that multiple databases in a cluster will eventually
> be used only for the cases where you *want* airtight separation between
> two collections of data.

Understood.

> Hence, I'm not particularly concerned by complaints about lack of
> cross-database functionality --- the folks who think they want that
> actually want cross-schema operations, which will work fine in 7.3.

Thank you for your time and comments.  I feel a lot "safer" about these
backups now.

Regards,
Andrew

Andrew Kohlsmith wrote:
> > > Is there a particular reason why plain text is forced?
> > Because pg_dumpall is producing a script file.
> > This is obviously not optimal, but it's not very clear how to do better.
>
> Agreed.  :-)
>
> I notice that pg_dumpall just uses a query to grab a list of databases and
> some information about them and then cycles through them and runs pg_dump for
> each one to dump it.  I could easily do this myself but that would mean that
> both pg_dumpall and whatever method I come up with do not guarantee
> referential integrity across databases (I'm specifically thinking about
> foreign keys).
>
> Now IIRC, Postgres doesn't allow foreign keys across databases so this point
> is moot at this time.  Is there a way to start a transaction at the start of
> the dump and hold it throughout successive connections, finally releasing it
> at the end?  Or is that on the TODO for whenever foreign keys can be across
> databases?

That is far off our TODO radar, perhaps never.  Sorry.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026