On Tue, Jul 17, 2012 at 1:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Jul 16, 2012 at 9:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> BTW, I wonder whether the code that checks for relfilenode conflict >>> when selecting a pg_class or relfilenode OID tries both file naming >>> conventions? If not, should we make it do so? > >> I don't believe it does, nor do I see what we would gain by making it to do >> so. > > What we would gain is ensuring that we aren't using the same relfilenode > for both a regular table and a temp table. Do you really want to assume > that such a conflict is 100% safe? It sounds pretty scary to me, and > even if we were sure the backend would never get confused, what about > client-side code that's looking at relfilenode?
Well, when I was working on that patch, I spent a lot of time trying to ensure that it was in fact safe. So I hope it is. Also, note that that could perfectly well happen anyway in any prior release if the relations happened to live in different tablespaces. Anyone assuming that <dboid,relfilenode> is unique is kidding themselves, because it is not guaranteed to be and has never been guaranteed to be. Yes, there could be client code out there that assumes <dboid,tsoid,relfilenode> is unique and such code will need adjustment for 9.1+. But I bet there isn't very much. The thing that broke a lot of client code in that commit was the replacement of relistemp with relpersistence; we already decided we didn't care about that (and it's too late to change it now anyway) so I can't really get excited about this. I think that code assuming that anything other than a RelFileNodeBackend is sufficient to uniquely identify a relation is just buggy, and if there is any, we should fix it. All remaining uses of RelFileNode rather than RelFileNodeBackend should be cases where we know that the backend ID has got to be InvalidBackendId. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers