github-actions[bot] commented on code in PR #69255:
URL: https://github.com/apache/doris/pull/69255#discussion_r4550677795
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/InternalCatalog.java:
##########
@@ -647,6 +658,7 @@ public void recoverDatabase(String dbName, long dbId,
String newDbName) throws D
if (!Strings.isNullOrEmpty(newDbName)) {
db.setNameWithLock(newDbName);
}
+ Env.getCurrentEnv().registerDbFunctionsById(db);
Review Comment:
[P2] Retire function IDs when database recovery aborts
A recoverable DROP retains the database's function-ID registrations, but
`CatalogRecycleBin.recoverDatabase()` removes the database from the recycle bin
before this method acquires the catalog lock and rechecks the destination name.
If that lock times out, or a concurrent `CREATE DATABASE` wins the destination
race, RECOVER throws before this publication block and leaves the database in
neither catalog nor recycle bin. Its IDs nevertheless remain in the new
`Env.id2Function` index, so every later `pythonUdfReport()` treats the orphan
functions as live and skips cleanup; with `auto_suspend=-1`, their dedicated
Python pools and package references remain indefinitely. The recovery failure
behavior already exists, but the new index must unregister functions on these
abandonment paths (or restore the database) so reconciliation can retire their
resources. Please cover recovery failure after recycle-bin removal.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
