| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Jacky Leng <lengjianquan(at)163(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Date: | 2007-10-18 09:28:30 |
| Message-ID: | 4717273E.9000300@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Jacky Leng 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.
>
> How about just allowing to use wal even WAL archiving is disabled?
> It seems that recovery of "XLOG_HEAP_NEWPAGE" record will do the
> right thing for us, look at "heap_xlog_newpage": XLogReadBuffer
> with init=true will extend the block rightly and rebuild it rightly.
>
> Someone may say that it's not worth recording xlog for operations
> such as copy_relation_data, but these operations shouldn't happen
> frequently.
Always using WAL would fix the problem, but it's a big performance hit.
WAL-logging doubles the amount of write I/O required.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-10-18 09:41:15 | Re: ts_rewrite aggregate API seems mighty ugly |
| Previous Message | Jacky Leng | 2007-10-18 07:28:45 | Re: Why copy_relation_data only use wal when WALarchiving is enabled |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2007-10-18 10:58:11 | Re: Why copy_relation_data only use wal whenWALarchivingis enabled |
| Previous Message | Hiroshi Saito | 2007-10-18 07:56:16 | Adjustment of test_fsync.c |