On 1/5/11 3:14 PM, Robert Haas wrote:
> I think that's probably a dead end - just to take one example, if you
> don't sync often enough, the standby might have transaction ID
> wraparound problems. Autovacuum on the master will prevent that for
> permanent tables, but not for an only-occasionally-updated copy of an
> unlogged table.
I think you're missing Agent M's idea: if you could write to unlogged
tables on the standby, then you could use application code to
periodically synch them.
Mind you, I personally don't find that idea that useful -- unlogged
tables are supposed to be for highly volatile data, after all. No doubt
M was thinking that in a failover situation, it would be better to have
stale data than none at all.
However, if an unlogged table created on the master could be available
for writing and initially empty on the standbys, it would give each
standby available temporary/buffer tables they could use. That would be
*really* useful.
Also, one of the obvious uses for unlogged tables is materialized views.
If unlogged tables don't get replicated, and can't be created on the
standby, then it severely limits their utility for this purpose.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
