Guillaume Smet wrote:
> On Jan 16, 2008 6:12 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote:
>> Tom Lane escribió:
>>> Possibly true, but if that's the underlying hardware then there's no
>>> performance benefit in breaking WAL up at all, no?
>> Selective PITR shipping.
>
> If it was possible to launch a PITR only on a given database, that
> could be a great feature too. We have at least one customer who runs
> every database in a separate cluster to be able to do PITR on only one
> database if needed (for example if someone executed a DROP TABLE by
> mistake).
Yeah, it sure would be nice.
I don't think it's going to work too well, though, not without major
changes at least. What would happen when you restore a PITR backup of
just one database? Would the other databases still be there in the
restored cluster? What state would they be in? After restoring one
database, and doing some stuff on it, could you ever "merge" those
changes with the rest of the cluster?
Mind you, there's more things shared between databases than the shared
catalogs. clog for example.
It might be useful for creating read-only copies of a master database,
but I don't see it being very useful/possible in general.
For more usefulness, we'd need to keep databases more separate from each
other than we do now. Databases would need to have their own transaction
counters, for example. Shared relations would obviously need major
changes for that to work. If we ultimately could separate databases so
that you could take a filesystem copy of a single database, and restore
it to another cluster, then per-database WAL and PITR would work.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
