From tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>
> What is concerned about is that the need to erase and delete the data file would be forgotten if the server crashes
duringstep
> 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
