Re: CompactCheckpointerRequestQueue versus pad bytes

On Tue, Jul 17, 2012 at 1:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jul 16, 2012 at 9:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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