Re: Why copy_relation_data only use wal whenWALarchivingis enabled

Florian G. Pflug wrote:
> Heikki Linnakangas wrote:
>> Tom Lane wrote:
>>> I tend to agree that truncating the file, and extending the fsync
>>> request mechanism to actually delete it after the next checkpoint,
>>> is the most reasonable route to a fix.
>>
>> Ok, I'll write a patch to do that.
>
> What is the argument against making relfilenodes globally unique by
> adding the xid and epoch of the creating transaction to the filename?
> Those 64 bits could be stuffed into 13 bytes by base-36 encoding
> (A-Z,0-9). The maximum length of a relfilenode would then be 10 + 1 + 13
> = 24, which any reasonable filesystem should support IMHO.

The size of would be xid + epoch + oid = 96 bits, not 64 bits.

That would work, but sounds like a much bigger change.

sizeof(RelFileNode) would increase from 12 to 20, so any data structure
that deals with RelFileNodes would take more memory. Hash function in
buffer manager would get more expensive. I remember seeing that showing
up in oprofile sometimes, but it'd need to be benchmarked to see if it
really matters.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com