>From tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> > What is concerned about is that the need to erase and delete the data file > would be forgotten if the server crashes during step > 3. If so, postmaster can do the job at startup, just like it deletes > temporary files (although it delays the startup.)
I suspect erasing and deleting the data file at startup is rather not acceptable. We can query to the table foo during erasing the table bar in normal conditions. However, if a crash happens and postmaster erase the table bar at startup, we can't execute any queries until the erasure is finished (and it would take long time). I'm afraid there will be someone complain about that. Can we erase the table after startup when a crash happens and also implement the function that returns whether the erasure of a specified table is completed or not? The users who want to know whether the erasure is completed can use that function and wait their tasks until the erasure is done, and the other users can execute query while erasing is processed. I have an another point to want to discuss. In current specification, every table will be completely erased if erase_command is set. The security conscious systems might want to delete all data completely, but isn't there a case that handles data that doesn't care about security? In that case, someone would want to choose which tables to be erased completely and which tables to be only dropped, which is achieved adding an option to "DROP TABLE" or implementing "ERASE TABLE" command. -- Yoshikazu Imai
