| From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Jacky Leng <lengjianquan(at)163(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Date: | 2007-10-18 14:18:21 |
| Message-ID: | 47176B2D.8090906@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
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.
regards, Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian G. Pflug | 2007-10-18 14:19:31 | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Previous Message | Heikki Linnakangas | 2007-10-18 14:15:00 | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Florian G. Pflug | 2007-10-18 14:19:31 | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Previous Message | Heikki Linnakangas | 2007-10-18 14:15:00 | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |