IssueTracker

I have a tech partner (Neudesic) who could really use this feature... Any sense if/when this might be supported?

+1 Gold support customer. Case  http://sfstory.googleplex.com/15440163

Is this being worked on?

+1 this is practically a dealbreaker for us. RDS exposes every option in postgres.conf, I have no idea why GCP only exposes a tiny subset of flags.

If we aren't allowed access to postgres.conf directly, we need these options exposed. How am I supposed to debug slow queries on our DB server if I can't even log them?

+1 - this is a real surprise as it's basic DBA functionality

any update on this? seems like a strong reason to switch to rds, a db without logs is like a car without a speedometer :(

+1 this a real problem for us also

Please provide an update on the current status of this issue, it has been several months now

+1 customer from fintech space

Same here..

+1 everyone needs slow query log

+1 we need this, too

+1 Surprised to learn that slow query logs are not supported.

This is highly important for us as we are having performance issues and no way real way to see what's not working well.

+1 we need it as well

+1

+1

+1 I have the difficulty with performance debugging as well

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1, having performance issues and need to trace slow queries

+1

+1

+1

+1

+1

+1

+1. Would be huge to have the auto_explain module.

I'd like to emphasize that this feature request should be not only about logging slow queries, but also about logging the query execution plans. The latter is what makes the auto_explain module so great, as compared to pg_stat_statements.

@here - some form of acknowledgement that this is a problem and is on a roadmap somewhere would be appreciated!

You are going to lose customers over the lack of a feature like this - particularly when Azure are doing some pretty interesting things with their performance tracking of queries...
https://docs.microsoft.com/en-us/azure/postgresql/concepts-query-performance-insight

+1

This is a dealbreaker for us as well.

+1

+1

+1

+1

+1

+1

+1

Good news - this has been addressed. From the cloud SQL release notes (https://cloud.google.com/sql/docs/release-notes):

> April 3, 2019
>
>   Support added for 122 MySQL flags and 96 Postgres flags

The supported flags for psql (https://cloud.google.com/sql/docs/postgres/flags) include log_min_duration_statement.

We confirmed it works by adding the following block to a google_sql_database_instance resource in our terraform code:

Have you try with 'create extension pg_stat_statements' for postgresql?

+1

While technically this feature has been enabled, it has been enabled in possibly the single least useful fashion possible.  You can, in fact, turn on the log_min_duration_statement flag, and that does enable postgres slow query logs.  So far so good, right?

Except that postgres query logs can include newlines, and whatever system google is using to export pg logs to stackdriver is not doing multiline matching.  So each line of the log gets its own stackdriver logging event.  And the query duration is not extracted as a field, so there is no straightforward way to set up a log-based metric from it.

This is technically better than nothing but only in the narrowest sense possible: there is no way to capture/export entire slow query events for alerting/analysis except by exporting the entire log and writing one's own postprocessor.

This is a really disappointing "fix" for an issue that is basic functionality for a hosted sql db and which took over a _year_ to implement.

^ +1

Don't want to seem rude or needy, but this feature (and some others basics) are by default in every competitors and even when no UI it's still more usable than stackdriver. We have to pay an additional service to do this, on top of the already very expensive cloud sql instance :/

As far as I knew PostgreSQL database flags are already configurable, ref: https://cloud.google.com/sql/docs/postgres/flags.
Therefore this ticket can be closed?

Me, too!

+1

+1

I don't think having slow logs sent to a system that doesn't digest them correctly (re the multiline issue) counts as supporting slow query logs. I do not think this should be closed.

+1

+1 to multiline support. The lack of structure of the logs also makes alerting extermely difficult, and it also makes creating log exclusions to control log volume (and therefore cost) nearly impossible.

+1

It is now over two years since this bug was opened, and approaching a year since I pointed out that slow query logging as implemented is entirely useless, and it remains just as useless.  (And auto_explain is still MIA, as are a long list of features that would be required merely for feature parity with GCP MySQL never mind Amazon RDS.)

Does anyone at google actually use this product or is it here because Amazon and Azure both offer it so therefore it's a checkbox that has to be checked when bidding on large contracts?  I'm currently scoping out a project to migrate from CloudSQL to self-managed postgres on kubernetes because we have been waiting years for _basic_ features to be implemented and it's crystal clear at this point that there is no timeline and no interest.

impossible to build a dashboard to identify the slow queries. Assuming this is because there's a lack of multi-line support?

+1.  This is a deal blocker for my client.  Newlines are resulting in customer not able to get any value out of slow query log entries.  This will result in them not 'certifying' Cloud SQL PostgreSQL use in their environment and thus block migration and net new opportunities.  

I don't think anyone at google actually reads these issues. It's hilarious that something so trivial hasn't been addressed after years.

FWIW, the "Query Insights" feature (https://cloud.google.com/sql/docs/postgres/insights-overview) now covers a lot of this, although I still know of no way to easily extract multi-line postgres logs from google logging.  

Cloud SQL for PostgreSQL has enhanced the support for multiline log entries in postgres.log. Before, when a log entry spanned multiple lines, each line was recorded as a separate entry in Cloud Logging. The lines are now recorded as a single entry in Cloud Logging for ease of query and processing. https://cloud.google.com/sql/docs/postgres/release-notes#September_14_2021

It seems that this problem is still there for mySql. any advice? thanks

Please see the long_query_time flag for MySQL.