I manage database clusters where the number of databases is a reason not to do
logical replication based upgrades, where pg_upgrade is far preferred instead.
If this were to be the case, I would be very concerned that a bunch of things
would have to change:
1. Shared catalogs would have txid problems unless you stay with global txids
and then how do local wal streams work there?
2. Possibility that suddenly streaming replication has the possibility of
different databases having different amounts of lag
3. Problems with io management on WAL on high throughput systems (I have
systems where a db cluster generates 10-20TB of WAL per day)
So I am not at all sure this would be a step in the right direction or worth
the work.
I agree these are all technical issues, but nevertheless - "implementation
details", which DBAs don't care about. What's important from a DBA's
perspective is not whether WAL is cluster-wide or database-wide, but whether
it's possible to manage backups/PITR/restores of individual databases in a more
convenient matter, which other RDBMS-vendors seem to provide.
I love PG, have been using it professionally since 6.5, and our company depends
on it, but there are things other RDBMS-vendors do better...
All,
Since we’re not limited by how many instances of Postgres we run, we actually
have a setup where we do live backups over a multi-node configuration. More
than one Postgres instance, and syncing between the databases as a scripted
process across database instances. This allows us to do some interesting
things like replicate to mobile hardware for Postgres in the field, etc.
The difference in how the DBs accomplish things are more related to taking
advantage of the capabilities in each software package vs comparing on a
function by function basis.
bobb
