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

Logging Warnings/Errors and Debugging info #398

Open
olirice opened this issue Jul 31, 2023 · 6 comments
Open

Logging Warnings/Errors and Debugging info #398

olirice opened this issue Jul 31, 2023 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@olirice
Copy link
Contributor

olirice commented Jul 31, 2023

GraphQL queries are typically passed as arguments to a prepared statement and are not logged. Transpired SQL queries executed via SPI are similarly unlogged. That makes it difficult for users to debug their own queries

This issue is to add debug level logging for:

  • GraphQL query
  • Transpiled SQL queries
  • The user's role and uid

with a trace_id

We should also add logging at the warning or error level for things like like naming collisions

@olirice olirice added the enhancement New feature or request label Jul 31, 2023
@olirice olirice self-assigned this Jul 31, 2023
@olirice
Copy link
Contributor Author

olirice commented Jul 31, 2023

cc @kav

@olirice
Copy link
Contributor Author

olirice commented Sep 14, 2023

current hold up on this is that we want to log the graphql queries at LOG level (which is just log!("graphql {statement}"); from pgrx prelude), but only if the log_statement in postgresql.conf is set to mod or all

@imor any ideas of how to check that setting efficiently?

@imor
Copy link
Contributor

imor commented Sep 15, 2023

Executing the following SQL once for each GraphQL query shouldn't add too much overhead:

select setting from pg_settings
where name = 'log_statement';

@olirice
Copy link
Contributor Author

olirice commented Sep 15, 2023

I'd rather not do that if we can avoid it. for now I'll add debug level logging since that isn't impacted

@imor
Copy link
Contributor

imor commented Sep 18, 2023

I'd rather not do that if we can avoid it. for now I'll add debug level logging since that isn't impacted

Is that because reading from pg_settings can be expensive, or there's some other reason? If the concern is inefficiency, we can also move this to when we read the context. That should be infrequent enough.

@olirice
Copy link
Contributor Author

olirice commented Sep 19, 2023

yeah the concern was efficiency. adding to the context is a good idea, I'll check that out

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

No branches or pull requests

2 participants