Re: How can I have 2 completely seperated databases in

Well, in postgresql you have a cluster, and inside the cluster, you have
databases, and inside the databases you have schemas.

You cannot cross database boundaries with transactions. i.e. you can
begin a transaction, insert into two databases and roll it back.
Transactions live within a single database, and each database is basically
a completely seperate entity.

However, they would shared the same postmaster process, and both be
accessed by going to port 5432. They would share log files, and most
likely share a directory (though there are a couple of different ways to
do that, it's not done most of the time, and doesn't gain most users a
lot.

So, you'll likely want one cluster / postmaster, with 2 or more databases
inside it.

Our main server at work handles 80 databases, some large, most small or
medium, and they are all seperate entities that I can dump seperately or
together, and give ownership to the user who needs to own that particular
db.

Will that get you what you want?

On Wed, 11 Feb 2004 hong(dot)ge(at)yale(dot)edu wrote:

> Thank you very much for your reply. I'd like to discuss the why.
>
> I don't think letting them share data and logs could gain me something.
> And if I have 2 databases totally not relevant, I think the most natural
> way is to make them totally seperated. Does the sharing buys me
> anything? If not, what's the reason of doing it?
>
> Thank you very much.
>
> --Hong Ge
>
>
> Quoting "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com>:
>
> > On Wed, 11 Feb 2004 hong(dot)ge(at)yale(dot)edu wrote:
> >
> > > Hi, all
> > >
> > > What should I do if I want to have 2 completely seperated databases
> > in
> > > PostgreSQL? I want each database to have its own data, log and
> > > everything needed to access that database. I don't want them to
> > share
> > > anything. Has anyone done this before? Or,
> > > could anyone give me some clue of how to do this?
> >
> > You're telling us what you want, but not the why. The why may help
> > us to
> > figure out both how to do it, and whether or not it's a good idea.
> >
>
>
>