On Sep 23, 2011, at 11:37 AM, Robert Haas wrote: > Another thing I'm not sure whether to worry about is the question of > where we store the vacuum generation information. I mean, if we store > it in pg_class, then what happens if the user does a manual update of > pg_class just as we're updating the vacuum generation information? We > had better make sure that there are no cases where we can accidentally > think that it's OK to reclaim dead line pointers that really still > have references, or we're going to end up with some awfully > difficult-to-find bugs... never mind the fact the possibility of the > user manually updating the value and hosing themselves. Of course, we > already have some of those issues - relfrozenxid probably has the same > problems - and I'm not 100% sure whether this one is any worse. It > would be really nice to have those non-transactional tables that > Alvaro keeps mumbling about, though, or some other way to store this > information.
Whenever I'd doing data modeling that involves both user modified data and system modified data, I always try to separate the two. That way you know that everything in the user-modify table can be changed at any time, and you can also lock down the system-data table to prevent the possibility of any user-driven changes. So, non-transactional tables or not, I think it would be a pretty good idea to build some separation into the catalog tables where there is the risk of a conflict between user activities and system activities. Actually, assuming that all catalog tables keep using the internal access methods, it might be wise to go as far as separate data that is maintained by separate system activities, to avoid conflicts between different parts of the system. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
