Issue 1:
Apache Airflow Provider(s)

google

Versions of Apache Airflow Providers

apache-airflow-providers-google 6.8.0

apache-airflow-providers-amazon 3.2.0

apache-airflow-providers-ftp 2.1.2

apache-airflow-providers-http 2.1.2

apache-airflow-providers-imap 2.2.3

apache-airflow-providers-postgres 4.1.0

apache-airflow-providers-sqlite 2.1.3

Apache Airflow version

2.2.4

Operating System

Debian GNU/Linux 11 (bullseye)

Deployment

Docker-Compose

Deployment details

No response

What happened

Context:

apache-airflow-providers-google=6.8.0 has package version requirement range of >=12.0.0,<14.0.1 for google-ads.

The lowest google-ads version to contain v9 is 14.1.0

Google-ads is deprecating v8, v7 on may 11th.

Issue:

The said google-airflow provider is blocking us from updating google-ads.

Is it possible to relax the restriction on google-ads package versions to include upto 14.1.0 ?

Thanks

What you think should happen instead

No response

How to reproduce

No response

Anything else

No response

Are you willing to submit PR?

Yes I am willing to submit a PR!

Code of Conduct

I agree to follow this project's Code of Conduct

Issue 2:
Apache Airflow version

2.0.2

What happened

2022-02-26 15:42:51 UTC [104192]: user=prod_airflow,db=prod_airflow,app=[unknown],client=10.80.166.208 STATEMENT: UPDATE dag SET next_dagrun='2022-02-26T15:32:50.428672+00:00'::timestamptz, next_dagrun_create_after='2022-02-26T15:42:50.428672+00:00'::timestamptz WHERE dag.dag_id = 'redacted_1'
2022-02-26 15:43:07 UTC [130186]: user=prod_airflow,db=prod_airflow,app=[unknown],client=10.80.166.208 ERROR: deadlock detected
2022-02-26 15:43:07 UTC [130186]: user=prod_airflow,db=prod_airflow,app=[unknown],client=10.80.166.208 DETAIL: Process 130186 waits for ShareLock on transaction 1728784371; blocked by process 130573.
Process 130573 waits for ShareLock on transaction 1728784356; blocked by process 130186.
Process 130186: UPDATE dag SET next_dagrun='2022-02-26T15:42:47.604016+00:00'::timestamptz, next_dagrun_create_after='2022-02-26T15:52:47.604016+00:00'::timestamptz WHERE dag.dag_id = 'redacted_1'
Process 130573: UPDATE dag SET last_parsed_time='2022-02-26T15:43:03.633626+00:00'::timestamptz, next_dagrun='2022-02-26T15:40:03.633649+00:00'::timestamptz WHERE dag.dag_id = 'redacted_2'
2022-02-26 15:43:07 UTC [130186]: user=prod_airflow,db=prod_airflow,app=[unknown],client=10.80.166.208 HINT: See server log for query details.
2022-02-26 15:43:07 UTC [130186]: user=prod_airflow,db=prod_airflow,app=[unknown],client=10.80.166.208 CONTEXT: while updating tuple (4,2) in relation "dag"
2022-02-26 15:43:07 UTC [130186]: user=prod_airflow,db=prod_airflow,app=[unknown],client=10.80.166.208 STATEMENT: UPDATE dag SET next_dagrun='2022-02-26T15:42:47.604016+00:00'::timestamptz, next_dagrun_create_after='2022-02-26T15:52:47.604016+00:00'::timestamptz WHERE dag.dag_id = 'redacted_1'

Likely places which conflict in the code:

airflow/airflow/models/dag.py

Line 2436
in
d726579

orm_dag.last_parsed_time = timezone.utcnow()

airflow/airflow/models/dag.py

Line 2919
in
d726579

self.next_dagrun_create_after = next_dagrun_info.run_after

What you expected to happen

No response

How to reproduce

We have 830 dags and this number keeps growing due to business requirements. No special steps to reproduce are required, it just happens every now and then, as would be expected. Increase fillfactor, perhaps?

Operating System

VERSION="20.04.3 LTS (Focal Fossa)"

Versions of Apache Airflow Providers

apache-airflow-providers-celery==1.0.1

apache-airflow-providers-ftp==1.0.1

apache-airflow-providers-http==1.1.0

apache-airflow-providers-imap==1.0.1

apache-airflow-providers-sqlite==1.0.1

Deployment

Other Docker-based deployment

Deployment details

$ docker --version
Docker version 19.03.5, build 633a0ea838

Postgres: psql (11.5 (Ubuntu 11.5-1.pgdg16.04+1))

Anything else

Multiple times a day.

Took remediation steps to reduce amount of rows on page:

prod_airflow=# alter table dag set (fillfactor = 10);
ALTER TABLE
prod_airflow=# vacuum full dag;
VACUUM

which reduced frequency to ~1/day.

Are you willing to submit PR?

Yes I am willing to submit a PR!

Code of Conduct

I agree to follow this project's Code of Conduct