Re: Why copy_relation_data only use wal when WALarchiving is enabled - Mailing list pgsql-hackers

From Jacky Leng
Subject Re: Why copy_relation_data only use wal when WALarchiving is enabled
Date
Msg-id ff71rk$2krc$1@news.hub.org
Whole thread Raw
In response to Why copy_relation_data only use wal when WAL archiving is enabled  ("Jacky Leng" <lengjianquan@163.com>)
List pgsql-hackers
> You need to set $PGDATA before running the script. And psql,pg_ctl and
> pg_resetxlog need to be in $PATH. After running the script, restart
> postmaster and run "SELECT * FROM t2". There should be one row in the
> table, but it's empty.

I've tried this script on "postgres (PostgreSQL) 8.3devel", and found that
T2 is not empty after recovery(just as it should be)---but the latest 
version
act just like what you said.

Then I see how cluster is done, and found that:
In "postgres (PostgreSQL) 8.3devel", unlike AlterTableSetTablespace (which
copys the whole relation block-by-block, and doesn't use wal under 
non-archiving
mode), Cluster copys the relation row-by-row(simple_heap_insert), which
always uses wal regardless of archiving mode. As wal exists, recovery will
cope with everything rightly.
The latest version acts differently probably because that it removes wal of 
cluser
under non-archiving mode.

So the conclusion is: we can replace wal mechanism with smgrimmedsync only 
if
relfilenode is not allowed to be reused, but this's not true, so what we 
should
keep wal.

Is it right? 




pgsql-hackers by date:

Previous
From: "Jacky Leng"
Date:
Subject: Re: Why copy_relation_data only use wal when WALarchiving is enabled
Next
From: "Jacky Leng"
Date:
Subject: Re: Why copy_relation_data only use wal when WALarchiving is enabled