From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AS OF queries |
Date: | 2017-12-25 03:26:36 |
Message-ID: | CAMsr+YEuDMLC3xFM+pcdbs9N4bRfTgDmh5nAdF+EaUtRfw_kfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24 December 2017 at 04:53, konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Huong Dangminh | 2017-12-25 04:26:11 | RE: User defined data types in Logical Replication |
Previous Message | Masahiko Sawada | 2017-12-25 01:58:41 | Re: User defined data types in Logical Replication |