On 12/12/13 11:13 AM, Robert Haas wrote:
> I think it sucks (that's the technical term) to have to wait for all
> currently-running transactions to terminate before being able to begin
> streaming changes, because that could take a long time. And you might
> well know that the long-running transaction which is rolling up
> enormous table A that you don't care about is never going to touch
> table B which you actually want to replicate. Now, ideally, the DBA
> would have a way to ignore that long-running transaction and force
> replication to start, perhaps with the caveat that if that
> long-running transaction actually does touch B after all then we have
> to resync. Your model's fine when we want to replicate the whole
> database, but a big part of why I want this feature is to allow
> finer-grained replication, down to the table level, or even slices of
> tables.
I know you're not going to attempt this for 9.4, but I want to mention a related case here. I've often wanted the
abilityto limit the tables a transaction can touch, so that it will not interfere with vacuuming other tables.
This would be useful when you have some tables that see very frequent updates/deletes in a database that also has to
supportlong-running transactions that don't hit those tables. You'd explicitly limit the tables your long-running
transactionwill touch and that way vacuum can ignore the long-running XID when calculating minimum tuple age for the
heavy-hittables.
If we had that capability it could also be used to improve the time required to get a snapshot for a limited set of
tables.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net