Re: Multiple logical databases
On Thu, 2006-02-02 at 10:23 -0500, Mark Woodward wrote:
If one db is REALLY REALLY huge and doesn't change, and a few
others are small and change often, pg_dumpall will spend most of its time
dumping the unchanging data.
My usual backup strategy does pg_dumpall -g to get the (tiny) global
data, and then pg_dump for each individual database. Quite apart from
anything else I prefer to have custom format dumps anyway, but I think
this should meet your need for less frequent dumping of some constant
database.
cheers
andrew
Import Notes
Reply to msg id not found: 16687.24.91.171.78.1138893824.squirrel@mail.mohawksoft.comReference msg id not found: 16687.24.91.171.78.1138893824.squirrel@mail.mohawksoft.com
"Mark Woodward" <pgsql@mohawksoft.com> writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt because of disk or something, the whole cluster is
affected.
This problem is not as large as you paint it, because most of the system
catalogs are *not* shared.
Does anyone see this as useful?
No...
regards, tom lane
Import Notes
Reply to msg id not found: 16687.24.91.171.78.1138893824.squirrel@mail.mohawksoft.comReference msg id not found: 16687.24.91.171.78.1138893824.squirrel@mail.mohawksoft.com | Resolved by subject fallback
"Mark Woodward" <pgsql@mohawksoft.com> writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt because of disk or something, the whole cluster is
affected.This problem is not as large as you paint it, because most of the system
catalogs are *not* shared.Does anyone see this as useful?
Seriously? No use at all? You don't see any purpose in controlling and
managing multiple postgresql postmaster processes from one central point?
Sure you don't want to think about this a little?
Mark Woodward wrote:
"Mark Woodward" <pgsql@mohawksoft.com> writes:
One of the problems with the current PostgreSQL design is that all the
databases operated by one postmaster server process are interlinked at
some core level. They all share the same system tables. If one database
becomes corrupt because of disk or something, the whole cluster is
affected.This problem is not as large as you paint it, because most of the system
catalogs are *not* shared.Does anyone see this as useful?
Seriously? No use at all? You don't see any purpose in controlling and
managing multiple postgresql postmaster processes from one central point?
pgAdmin does so. IMHO it's totally sufficient to handle this on a client
side level.
Regards,
Andreas
Mark Woodward wrote:
Seriously? No use at all? You don't see any purpose in controlling and
managing multiple postgresql postmaster processes from one central point?
I'd rather spend effort in fixing the problems that arise from big
databases; for example Hannu's patch for concurrent vacuum attacks one
of the problems that IMHO are important. More elaborate partitioning
does too.
Anyway, if you're very excited about it, I don't think it's impossible
to code a super-postmaster that would redirect a client to the real
postmaster. I even think it can be done without modifying the regular
postmaster.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support