sql: investigate zone config behaviour during dropping of a {table,database}

[justinj]

@nvanbenschoten and I were attempting to drop a database with a GC TTL of 30 seconds, but after we dropped it, it seemed that the zone config we had set up no longer applied, so it fell back to the .default zone config. We should clarify and document if this is the actual expected behaviour in this kind of situation.

cc @knz

[knz]

This needs to cross-reference #28901.

[a-robinson]

I think this is a dupe of #24179?

[petermattis]

@knz Can you elaborate why this is a core issue? It feels like this is something under the control of the schema change folks. In particular, it seems like dropping a database should not delete the associated zone config until all of the table drops have completed.

Cc @vivekmenezes

[knz]

oh in my mind the application of zones to ranges is a matter of the replication layer.

Maybe the thing is cross-layer actually.

[petermattis]

Yeah, it's possible it is cross layer. My guess from reading this issue and knowing a bit of the code is that the problem (or UX surprise) is in the schema change handling. Assigning to @vivekmenezes for more detailed diagnosis.

[vivekmenezes]

This issue couldn't be resolved originally because the database descriptor would get dropped immediately. But now with the creation of a job for the DROP DATABASE being done for #19004
we can have the job delete the zone config after it has completed dropping all the table data.

[vivekmenezes]

this is a dup of #24179