Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

search: limit queries to 20s #854

Merged
merged 1 commit into from Jan 30, 2021
Merged

search: limit queries to 20s #854

merged 1 commit into from Jan 30, 2021

Conversation

grahamc
Copy link
Member

@grahamc grahamc commented Jan 30, 2021

Even 20s is really long, but it cuts off queries which are today
running for 500+s.

@grahamc
Copy link
Member Author

grahamc commented Jan 30, 2021

For example, https://hydra.nixos.org/search?query=chromium takes about 16s in total. Changing to pkgs.chromium takes 500+s.

builds => $c->stash->{builds},
buildsdrv => $c->stash->{buildsdrv} };
$c->model('DB')->schema->txn_do(sub {
$c->model('DB')->schema->storage->dbh->prepare("SET statement_timeout = 20000;")->execute();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the difference compared to SET LOCAL statement_timeout …? Does this have the possibility to escape the transaction?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to https://www.postgresql.org/docs/10/sql-set.html this would set the timeout for all other queries, even those outside of the transaction. We probably want SET LOCAL instead:

The effects of SET LOCAL last only till the end of the current transaction, whether committed or not. A special case is SET followed by SET LOCAL within a single transaction: the SET LOCAL value will be seen until the end of the transaction, but afterwards (if the transaction is committed) the SET value will take effect.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch.

If SET (or equivalently SET SESSION) is issued within a transaction that is later aborted, the effects of the SET command disappear when the transaction is rolled back. Once the surrounding transaction is committed, the effects will persist until the end of the session, unless overridden by another SET.

The effects of SET LOCAL last only till the end of the current transaction, whether committed or not. A special case is SET followed by SET LOCAL within a single transaction: the SET LOCAL value will be seen until the end of the transaction, but afterwards (if the transaction is committed) the SET value will take effect.

Changing to SET LOCAL.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, tested locally that it still works. Thanks!

builds => $c->stash->{builds},
buildsdrv => $c->stash->{buildsdrv} };
$c->model('DB')->schema->txn_do(sub {
$c->model('DB')->schema->storage->dbh->prepare("SET LOCAL statement_timeout = 20000;")->execute();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why prepare->execute rather than just do?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No reason than muddling through the DBIx docs made me just find other examples in Hydra 😅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixup'd.

Even 20s is really long, but it cuts off queries which are today
running for 500+s.
@grahamc grahamc merged commit aaf16d5 into master Jan 30, 2021
@grahamc grahamc deleted the limit-query-time branch January 30, 2021 16:55
@edolstra
Copy link
Member

Maybe we should just remove the search feature if it's that expensive. Or limit it to things that can be queried efficiently.

@grahamc
Copy link
Member Author

grahamc commented Jan 31, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants