Re: Why copy_relation_data only use wal whenWALarchivingis enabled - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Why copy_relation_data only use wal whenWALarchivingis enabled
Date
Msg-id 471783EC.9040200@phlo.org
Whole thread Raw
In response to Re: Why copy_relation_data only use wal whenWALarchivingis enabled  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> What is the argument against making relfilenodes globally unique by adding
>> the xid and epoch of the creating transaction to the filename?
> 
> 1. Zero chance of ever backpatching.  (I know I said I wasn't excited about
> that, but it's still a strike against a proposed fix.)
> 
> 2. Adds new fields to RelFileNode, which will be a major code change, and
> possibly a noticeable performance hit (bigger hashtable keys).
> 
> 3. Adds new columns to pg_class, which is a real PITA ...
> 
> 4. Breaks oid2name and all similar code that knows about relfilenode.

Ah, Ok. I was under the impression that relfilenode in pg_class is a string of
some kind. In that case only GetNewRelFileNode would have needed patching...
But that is obviously not the case, as I realized now :-(

Thanks for setting me straight ;-)

regards, Florian Pflug


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: max_prepared_transactions default ... why 5?
Next
From: Gregory Stark
Date:
Subject: Re: ts_rewrite aggregate API seems mighty ugly