On Tue, Oct 22, 2013 at 1:08 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> It seems to me that you have to think of the CTID map as tied to a >> relfilenode; if you try to use one relfilenode's map with a different >> relfilenode, it's obviously not going to work. So don't do that. > > It has to be tied to relfilenode (+ctid) *and* transaction > unfortunately.
I agree that it does, but it doesn't seem particularly unfortunate to me. >> That strikes me as a flaw in the implementation rather than the idea. >> You're presupposing a patch where the necessary information is >> available in WAL yet you don't make use of it at the proper time. > > The problem is that the mapping would be somewhere *ahead* from the > transaction/WAL we're currently decoding. We'd need to read ahead till > we find the correct one. Yes, I think that's what you need to do. > But I think I mainly misunderstood what you proposed. That mapping could > be written besides relfilenode, instead of into the WAL. Then my > imagined problem doesn't exist anymore. That's pretty ugly. I think it should be written into WAL. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
