> Jacky Leng wrote:
>> If I run the database under non-archiving mode, and execute the following
>> command:
>>      alter table t set tablespace tblspc1;
>> Isn't it possible that the "new t" cann't be recovered?
> No. At the end of copy_relation_data we call smgrimmedsync, which fsyncs
> the new relation file.

Usually it's true, but how about this situation:
* First, do the following series:
    * Create two tablespace SPC1, SPC2;
    * Create table T1 in SPC1 and insert some values into it, suppose T1's 
oid/relfilenode is OID1;
    * Drop table T1;----------OID1 was released in pg_class and can be 
    * Do anything that will make the next oid that'll be allocated from 
pg_class be OID1, e.g. insert
      many many tuples into a relation with oid;
    * Create table T2 in SPC2, and insert some values into it, and its 
oid/relfilenode is OID1;
    * Alter table T2 set tablespace SPC1;---------T2 goes to SPC1 and uses 
the same file name with old T1;
* Second, suppose that no checkpoint has occured during the upper 
series--authough not quite possible;
* Kill the database abnormaly;
* Restart the database;

Let's analyze what will happen during the recovery process:
* When T1 is re-created, it finds that its file has already been 
there--actually this file is T2's;
* "T1" ' s file(actually T2's) is re-dropped;
* ....
* T2 is re-created, and finds that its file has disappeared, so it re-create 
* As copy_relation_data didn't record any xlog about T2's AlterTableSpace 
  after recovery, we'll find that T2 is empty!!!

> -- 
>  Heikki Linnakangas
>  EnterpriseDB   http://www.enterprisedb.com
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>               http://www.postgresql.org/docs/faq

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to