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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
