* Josh Berkus <josh@agliodbs.com> [080529 11:52]:
> Marko,
>
> >But Tom's mail gave me impression core wants to wait until we get "perfect"
> >read-only slave implementation so we wait with it until 8.6, which does
> >not seem sensible. If we can do slightly inefficient (but simple)
> >implementation
> >right now, I see no reason to reject it, we can always improve it later.
>
> That's incorrect. We're looking for a workable solution. If we could
> get one for 8.4, that would be brilliant but we think it's going to be
> harder than that.
>
> Publishing the XIDs back to the master is one possibility. We also
> looked at using "spillover segments" for vacuumed rows, but that seemed
> even less viable.
>
> I'm also thinking, for *async replication*, that we could simply halt
> replication on the slave whenever a transaction passes minxid on the
> master. However, the main focus will be on synchrounous hot standby.
Or, instead of statement timeout killing statements on the RO slave,
simply kill any "old" transactions on the RO slave. "Old" in the sense
that the master's xmin has passed it. And it's just an exersise in
controlling the age of xmin on the master, which could even be done
user-side.
Doesn't fit all, but no one size does... It would work for where you're
hammering your slaves with a diverse set of high-velocity short queries
that you're trying to avoid on the master...
An option to "pause reply (making it async)" or "abort transactions
(for sync)" might make it possible to easily run an async slave for slow
reporting queries, and a sync slave for short queries.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.