On 2013-06-28 12:26:52 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On the other hand, I can't entirely shake the feeling that adding the > > information into WAL would be more reliable. > > That feeling has been nagging at me too. I can't demonstrate that > there's a problem when an ALTER TABLE is in process of rewriting a table > into a new relfilenode number, but I don't have a warm fuzzy feeling > about the reliability of reverse lookups for this.
I am pretty sure the mapping thing works, but it indeed requires some complexity. And it's harder to debug because when you want to understand what's going on the relfilenodes involved aren't in the catalog anymore. > At the very least > it's going to require some hard-to-verify restriction about how we > can't start doing changeset reconstruction in the middle of a > transaction that's doing DDL. Currently changeset extraction needs to wait (and does so) till it found a point where it has seen the start of all in-progress transactions. All transaction that *commit* after the last partiall observed in-progress transaction finished can be decoded. To make that point visible for external tools to synchronize - e.g. pg_dump - it exports the snapshot of exactly the moment when that last in-progress transaction committed. So, from what I gather there's a slight leaning towards *not* storing the relation's oid in the WAL. Which means the concerns about the uniqueness issues with the syscaches need to be addressed. So far I know of three solutions: 1) develop a custom caching/mapping module 2) Make sure InvalidOid's (the only possible duplicate) can't end up the syscache by adding a hook that prevents that on the catcache level 3) Make sure that there can't be any duplicates by storing the oid of the relation in a mapped relations relfilenode Opinions? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
