From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Catalog/Metadata consistency during changeset extraction from wal |
Date: | 2012-06-22 13:22:03 |
Message-ID: | 201206221522.04019.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thursday, June 21, 2012 05:40:08 PM Andres Freund wrote:
> On Thursday, June 21, 2012 03:56:54 PM Florian Pflug wrote:
> > On Jun21, 2012, at 13:41 , Andres Freund wrote:
> > > 3b)
> > > Ensure that enough information in the catalog remains by fudging the
> > > xmin horizon. Then reassemble an appropriate snapshot to read the
> > > catalog as the tuple in question has seen it.
> >
> > The ComboCID machinery makes that quite a bit harder, I fear. If a tuple
> > is updated multiple times by the same transaction, you cannot decide
> > whether a tuple was visible in a certain snapshot unless you have access
> > to the updating backend's ComboCID hash.
>
> Thats a very good point. Not sure how I forgot that.
>
> It think it might be possible to reconstruct a sensible combocid mapping
> from the walstream. Let me think about it for a while...
I have a very, very preliminary thing which seems to work somewhat. I just log
(cmin, cmax) additionally for every modified catalog tuple into the wal and so
far that seems to be enough.
Do you happen to have suggestions for other problematic things to look into
before I put more time into it?
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-06-22 13:45:42 | Re: Pruning the TODO list |
Previous Message | Robert Haas | 2012-06-22 13:15:33 | Re: Pruning the TODO list |