### Apache Airflow version

2.5.3

### What happened

When I call the airflow initdb function, it outputs these lines to the log

INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.

### What you think should happen instead

There should be a mechanism to disable these logs, or they should just be set to WARN by default

### How to reproduce

Set up a new postgres connection and call:

from airflow.utils.db import initdb
initdb()

### Operating System

MacOS

### Versions of Apache Airflow Providers

_No response_

### Deployment

Virtualenv installation

### Deployment details

_No response_

### Anything else

_No response_

### Are you willing to submit PR?

- [X] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

)
        else:
            delete = source_table.delete().where(
                and_(col == target_table.c[col.name] for col in source_table.primary_key.columns)
            )
        log.debug(delete.compile())
        session.execute(delete)
    session.commit()
    log.debug("exiting move function")
def _dangling_against_dag_run(session, source_table, dag_run):
    """
    Given a source table, we generate a subquery that will return 1 for every row that
    has a dagrun.
    """
    source_to_dag_run_join_cond = and_(
        source_table.c.dag_id == dag_run.c.dag_id,
        source_table.c.execution_date == dag_run.c.execution_date,
    )
    return (
        session.query(*[c.label(c.name) for c in source_table.c])
        .join(dag_run, source_to_dag_run_join_cond, isouter=True)
        .filter(dag_run.c.dag_id.is_(None))
    )
def _dangling_against_task_instance(session, source_table, dag_run, task_instance):
    """
    Given a source table, we generate a subquery that will return 1 for every row that
    has a valid task instance (and associated dagrun).
    This is used to identify rows that need to be removed from tables prior to adding a TI fk.
    Since this check is applied prior to running the migrations, we have to use different
    query logic depending on which revision the database is at.