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

Reply via email to