Spark: Handle concurrently dropped view during CREATE OR REPLACE

[nastra]

This is related to #9596 (comment). If the view is concurrently dropped during CREATE OR REPLACE we create the view in CreateV2ViewExec

[amogh-jahagirdar]

Just had a comment on another possible concurrent case, but I don't consider it a blocker since it's not practical for views, and in the end the query would fail and a user could retry (so there's no bad outcome of the concurrent case).

[amogh-jahagirdar]

I don't think it really matters in practice because it seems unlikely to happen but if we want to be considerate of a concurrent drop during the create or replace, wouldn't we also want to be considerate if someone also concurrently creates the view right after dropping it?

So the timing would look something like:

1.) Thread 1 starts a CREATE OR REPLACE
2.) Thread 2 performs DROP
3.) Thread 2 has executed a createView
4.) Thread 1 catches the NoSuchViewException and calls createView
5.) Thread 1 fails because it was a normal create and the view already exists.

It'd be equally odd if CREATE OR REPLACE fails due to "ViewAlreadyExists" exception.
In that case I think this would need to be a re-execution of the entire createOrReplace instead of just a create.

Again, I don't think it's a really practical case but it seems feasible to handle if we want to handle the "NoSuchViewException" case as well

[nastra]

In that case I think this would need to be a re-execution of the entire createOrReplace instead of just a create.

I agree, that's probably the best to just issue the replace again here

[nastra]

Thanks for reviewing @amogh-jahagirdar