On 24 December 2017 at 04:53, konstantin knizhnik <k.knizh...@postgrespro.ru > wrote:
> > > But what if I just forbid to change recent_global_xmin? > If it is stalled at FirstNormalTransactionId and never changed? > Will it protect all versions from been deleted? > That's totally impractical, you'd have unbounded bloat and a nonfunctional system in no time. You'd need a mechanism - akin to what we have with replication slots - to set a threshold for age. > Then there's another issue that logical replication has had to deal > > with -- catalog changes. You can't start looking at tuples that have a > > different structure than the current catalog unless you can figure out > > how to use the logical replication infrastructure to use the old > > catalogs. That's a huge problem to bite off and probably can just be > > left for another day if you can find a way to reliably detect the > > problem and raise an error if the schema is inconsistent. > > > Yes, catalog changes this is another problem of time travel. > I do not know any suitable way to handle several different catalog > snapshots in one query. > I doubt it's practical unless you can extract it to subplans that can be materialized separately. Even then, UDTs, rowtype results, etc... > The question is how we should handle such catalog changes if them are > happen. Ideally we should not allow to move back beyond this point. > Unfortunately it is not so easy to implement. > I think you can learn a lot from studying logical decoding here. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
