Wednesday, June 30, 2021

[google-cloud-sql-discuss] Re: Consistent "Segmentation fault" error in logs when running a query

Quick bump. @google what is the status of this? We are seeing similar behavior where the only fix was disabling insights in production. Any movement here?

On Wednesday, April 14, 2021 at 10:11:30 PM UTC-7 Andrew K. wrote:
After prolonged testing, I have an update: to completely stop segfaults, Query Insights must be disabled after all. Merely disabling application tags makes them less frequent, but doesn't prevent them entirely.
On Thursday, April 15, 2021 at 2:39:51 AM UTC+12 e...@contractbook.dk wrote:
Hi

> Would you be able to confirm if you are still able to see the segmentation fault errors? 

Yes, I confirm this. The last one per our logs happened today at 2021-04-13 08:11:32.469 UTC. The segmentation errors are not extremely common (due to low traffic on staging environment), but happen every day, once or twice. This may become a deal breaker should be plan to move our production DB to Google Cloud though.

> does the query involve a LEFT JOIN?

The query definition itself has two JOINs, although not LEFT JOINs. However, one of the joined relations is a view that is defined to have LEFT JOINs in it.

Noted on the SO question. I am not sure what to take from it though...

Noted on the issue tracker too. I'll gather up the info I have so far and will publish there. Thank you!
On Monday, April 12, 2021 at 12:24:55 PM UTC+3 jli...@google.com wrote:
Hello, 

Would you be able to confirm if you are still able to see the segmentation fault errors? If so, would you be able to please provide the most recent timestamp of the occurrence. 

Also, would you be able to provide a little more details regarding the query? As per Andrew's question, does the query involve a LEFT JOIN? According to the post presented here [1], this may be due to a PostgreSQL bug. Would you be able to verify this and get back to use with this information? 

Better yet, I would suggest you bring this issue up via public issue tracker [2], as this will allow for a more in depth investigation into the segmentation fault; at the same time bring the issue closer to the Cloud SQL team for further inspection.


On Tuesday, March 30, 2021 at 1:10:32 PM UTC-4 Andrew K. wrote:
Does this query involve either a LEFT JOIN or aggregate functions? We have a very similar issue with Cloud SQL Postgres 12.5, with four different queries causing segmentation faults, and these are the only similarities between then. So far we were not able to reproduce the segfaults on a local PG instance running the same DB and queries, and unfortunately it's not possible to attach a debugger to Cloud SQL (as far as we know).

On Tuesday, March 30, 2021 at 3:23:04 AM UTC+13 e...@contractbook.dk wrote:
We're seeing a "Segmentation fault" error in logs for our staging environment, caused by a single specific DB query.

I am unable to replicate the problem consistently by running the same query manually, but we see the issue in logs basically every day now.

Our environment is: PostgreSQL 13.1, the DB tier is "db-custom-1-3840".

In the 1st half of February, we were seeing "Segmentation fault" in relation to another DB query & different DB instance. That issue somehow got self-resolved around Feb 15.

I'd love to provide more info to diagnose this – is there any other info I could provide that would help solve this case? Otherwise, would it be possible for a Google Cloud SQL engineer look into this for us?

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/bf86dd56-7ee2-4f0b-a023-d2aec5ee58f2n%40googlegroups.com.

[google-cloud-sql-discuss] Single row output at random times

Sometimes the view that I created only outputs a single row of data.

The underlying code is correct and the base tables are up to date. Most of the time it works fine but at random times I only get a single row of data which should be included in the final output but is also an outlier amongst all the other expected rows. Re-checked the code and base queries and tables.

Email from People at capillarytech.com may not represent Official Policy of Capillary Technologies unless explicitly stated. Please see our Privacy Policy for details. Contents of this Email are confidential. Please contact Sender if you have received this Email in error.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/84ee17bf-bb95-4060-9629-d6d230032906n%40googlegroups.com.

Tuesday, June 29, 2021

[google-cloud-sql-discuss] Postgres using foreign data wrapper extesion results permission denied for relation

Hello all! I have recently finish a new post in StackOverflow regarding an issue i having serious difficulties. I hope to find a charity soul that may help me in this crusade.
Thanks in advance!

Greetings
Vitu

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/cf017687-a8a5-4a9b-903a-3c1a06f4fa4en%40googlegroups.com.

Friday, June 25, 2021

[google-cloud-sql-discuss] Re: Getting pymysql.err.OperationalError: (2013, 'Lost connection to MySQL server during query')

Hello,

You can check this documentation [1] that explains the three different causes of this error and the possible solutions for each case.

[1] https://dev.mysql.com/doc/refman/5.7/en/error-lost-connection.html

On Thursday, June 24, 2021 at 9:02:53 AM UTC+2 mike.b...@puzzle.consulting wrote:
I am running a Python script in a GCP Compute Engine VM to connect to the MySQL instance, and I am getting this error. I am using pymysql for connection. I tracked the error to this file 
`/usr/local/lib/python3.5/dist-packages/pymysql/connections.py` line 703, in _read_bytes and to the following lines of code

```
if len(data) < num_bytes:
        self._force_close()
        raise err.OperationalError(
        CR.CR_SERVER_LOST, "Lost connection to MySQL server during query")
```

Has anyone experienced this issue before?

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/0fd1cc0e-650f-4b6f-a1be-f754c401e1bdn%40googlegroups.com.

[google-cloud-sql-discuss] Re: Query Insights Downtime

Hello,

As per this documentation [1] when enabling Query Insights, all the other operations will be momentarily suspended. The instance will not restart.

[1] https://cloud.google.com/sql/docs/postgres/using-insights#opening_the_query_insights_dashboard

On Wednesday, June 23, 2021 at 9:03:15 AM UTC+2 dwwo...@gmail.com wrote:
I created a clone of my db and enabled query insights on it. While it was being enabled (2-5 minutes), I was not able to connect to the db.

It seems like there will be downtime if you enable query insights.

Note that there was no indication anywhere in the UI or in the documentation that enabling query insights would incur downtime.


On Friday, February 5, 2021 at 12:42:38 AM UTC-8 Daniel Woelfel wrote:
Will enabling Query Insights in a Postgres database cause any downtime or a restart?

I've had problems in the past with the cloud sql UI not indicating that an operation will cause downtime, so I'm being extra careful here.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/dc377f71-0604-4e5c-9f87-b1c4a3f34a5en%40googlegroups.com.

Re: [google-cloud-sql-discuss] Re: Upgrading Postgres from 9.6 to 13

when we are storing our postgres backup in our dr cloudsql it is not importing and not restoring what can be cause in this case ??


On Wed, 2 Jun 2021 at 15:18, 'goya' via Google Cloud SQL discuss <google-cloud-sql-discuss@googlegroups.com> wrote:

I have not been able to find a way to keep the IP as an upgrade of the Postgres version requires you to create a new Cloud SQL instance [1] and there is no way to assign an IP to it. 


An option to prevent this situation is to use the Cloud SQL Auth proxy [2]. Using it will avoid the need of connecting to the instance using a static IP



[1]: https://cloud.google.com/sql/docs/postgres/upgrade-db

[2]: https://cloud.google.com/sql/docs/postgres/sql-proxy#what_the_provides

On Tuesday, June 1, 2021 at 9:05:25 AM UTC+2 bogu...@gmail.com wrote:
I'd like to be able to upgrade my existing cloudsql postgres 9.6 instance to 11 to use some new pg 11 features.


I need to keep the same IP as the instance with 9.6. There are many applications.

I accept suggestion of less important strategies.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/61e27a90-0792-453c-b12f-85a8ac188ad4n%40googlegroups.com.


--
Regards
Biswanath Giri
Mob:9560016514

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/CAEJ8qt80yRZd4TCwc2O-ToVD5bJHnr-Hvafrhu%3DcN1OgX5fyrA%40mail.gmail.com.

Wednesday, June 23, 2021

[google-cloud-sql-discuss] Getting pymysql.err.OperationalError: (2013, 'Lost connection to MySQL server during query')

I am running a Python script in a GCP Compute Engine VM to connect to the MySQL instance, and I am getting this error. I am using pymysql for connection. I tracked the error to this file 
`/usr/local/lib/python3.5/dist-packages/pymysql/connections.py` line 703, in _read_bytes and to the following lines of code

```
if len(data) < num_bytes:
        self._force_close()
        raise err.OperationalError(
        CR.CR_SERVER_LOST, "Lost connection to MySQL server during query")
```

Has anyone experienced this issue before?

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/14c179b9-dcb6-44ad-8b27-f2aee04adb17n%40googlegroups.com.

Tuesday, June 22, 2021

[google-cloud-sql-discuss] Re: Query Insights Downtime

I created a clone of my db and enabled query insights on it. While it was being enabled (2-5 minutes), I was not able to connect to the db.

It seems like there will be downtime if you enable query insights.

Note that there was no indication anywhere in the UI or in the documentation that enabling query insights would incur downtime.


On Friday, February 5, 2021 at 12:42:38 AM UTC-8 Daniel Woelfel wrote:
Will enabling Query Insights in a Postgres database cause any downtime or a restart?

I've had problems in the past with the cloud sql UI not indicating that an operation will cause downtime, so I'm being extra careful here.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/bcd14bf1-14a7-440b-9738-450d5393b90fn%40googlegroups.com.

Tuesday, June 15, 2021

[google-cloud-sql-discuss] Re: MySQL "Lightweight" vs. "Standard" instances


Let me be more specific , it refers to the db-n1-standard machine type, it calculates(https://cloud.google.com/sql/pricing#cpu-mem-pricing) based on the vCPUs and memory that you want. 
On Tuesday, June 15, 2021 at 12:35:55 PM UTC-4 wushawn wrote:

Lightweight give you access to preset configuration 1 vCPU, 3.75 GB - 2 vCPU, 3.75 GB - 4 vCPU, 3.75 GB and
On Tuesday, March 23, 2021 at 5:27:18 PM UTC-4 wushawn wrote:

the legacy machine type name  is mapped to its equivalent string in the db-custom-_CPU_-_RAM_ format.  Here is the table(https://cloud.google.com/sql/docs/mysql/instance-settings#machine-type-2ndgen) you can refer to .


On Tuesday, March 23, 2021 at 11:43:26 AM UTC-4 dmi...@gmail.com wrote:
Hi,

does anyone have any specifics what machine types the "Lightweight" vs. the "Standard" machine type maps to?

I suspect "Lightweight" is based on E2 and "Standard" on N1.

When creating a new instance this is the selection for the machine type now:

Screenshot_20210322_202500.png

It's a bit annoying as the GCP calculator doesn't have a matching selection so figuring out pricing is kinda hard.

Thanks for any hints on how to figure out the pricing!




--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/81d30620-bfc9-4131-b6c7-3bd15fc9f0f3n%40googlegroups.com.

[google-cloud-sql-discuss] Re: MySQL "Lightweight" vs. "Standard" instances


Lightweight give you access to preset configuration 1 vCPU, 3.75 GB - 2 vCPU, 3.75 GB - 4 vCPU, 3.75 GB and
On Tuesday, March 23, 2021 at 5:27:18 PM UTC-4 wushawn wrote:

the legacy machine type name  is mapped to its equivalent string in the db-custom-_CPU_-_RAM_ format.  Here is the table(https://cloud.google.com/sql/docs/mysql/instance-settings#machine-type-2ndgen) you can refer to .


On Tuesday, March 23, 2021 at 11:43:26 AM UTC-4 dmi...@gmail.com wrote:
Hi,

does anyone have any specifics what machine types the "Lightweight" vs. the "Standard" machine type maps to?

I suspect "Lightweight" is based on E2 and "Standard" on N1.

When creating a new instance this is the selection for the machine type now:

Screenshot_20210322_202500.png

It's a bit annoying as the GCP calculator doesn't have a matching selection so figuring out pricing is kinda hard.

Thanks for any hints on how to figure out the pricing!




--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/35c6b9b6-47a1-4e0c-b81c-2c66e43de43an%40googlegroups.com.

[google-cloud-sql-discuss] Re: Major Google Cloud SQL issue - SQL Cloud unresponsive

It is unlikely that you are being affected by the exact same issue, as the previous issue was fixed almost 3 years ago. You seem to instead be affected by this another situation that is currently being investigated by the Cloud SQL product team. You can receive updated on it by staring this Issue Tracker thread [1].


[1]: https://issuetracker.google.com/190934612

On Tuesday, June 15, 2021 at 9:05:43 AM UTC+2 will....@mcdbeau.me wrote:

Every time a new instance of our App Engine app spins up (due to automatic scaling), we get the error you see below.  I have included the logs for the boot up sequence of one of our app engine instances:

It seems to have to do with initial connects to our db? (elate-postgresql) Which is our Cloud SQL db

Screen Shot 2021-06-14 at 9.05.26 AM.png
On Friday, June 11, 2021 at 2:04:27 PM UTC-7 yananc wrote:

Hi Will,

The original issue was reported almost 2 years ago, so we are hardly able to conclude you are currently being affected by the same issue. It will be much better if you could provide more information (symptom, error logs, metric abnormalities, etc) to facilitate further investigation. Thank you.

On Thursday, June 10, 2021 at 6:13:47 PM UTC-4 will....@mcdbeau.me wrote:
This error seems to be back. We started experiencing this on Google Cloud SQL postgresql, on June 4th 20201

On Wednesday, August 21, 2019 at 3:17:33 PM UTC-7 George (Cloud Platform Support) wrote:
Hello Hugues, 

You are right, something on Google's end was not going as expected, which explains your connectivity issues on 7 August. The issue has been fixed meanwhile. You may check Cloud Status Dashboard for such occurrences any time. 

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/71ae244b-0fbd-4ad7-a486-2ed590f41baan%40googlegroups.com.

Monday, June 14, 2021

[google-cloud-sql-discuss] Re: Major Google Cloud SQL issue - SQL Cloud unresponsive


Every time a new instance of our App Engine app spins up (due to automatic scaling), we get the error you see below.  I have included the logs for the boot up sequence of one of our app engine instances:

It seems to have to do with initial connects to our db? (elate-postgresql) Which is our Cloud SQL db

Screen Shot 2021-06-14 at 9.05.26 AM.png
On Friday, June 11, 2021 at 2:04:27 PM UTC-7 yananc wrote:

Hi Will,

The original issue was reported almost 2 years ago, so we are hardly able to conclude you are currently being affected by the same issue. It will be much better if you could provide more information (symptom, error logs, metric abnormalities, etc) to facilitate further investigation. Thank you.

On Thursday, June 10, 2021 at 6:13:47 PM UTC-4 will....@mcdbeau.me wrote:
This error seems to be back. We started experiencing this on Google Cloud SQL postgresql, on June 4th 20201

On Wednesday, August 21, 2019 at 3:17:33 PM UTC-7 George (Cloud Platform Support) wrote:
Hello Hugues, 

You are right, something on Google's end was not going as expected, which explains your connectivity issues on 7 August. The issue has been fixed meanwhile. You may check Cloud Status Dashboard for such occurrences any time. 

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/af1b7250-76f0-4cb6-b222-62ebc06d0273n%40googlegroups.com.

Friday, June 11, 2021

[google-cloud-sql-discuss] Re: I/O performance (mostly write?) intermittently goes severely low

One month after implementing serialization of the ingesting processes no performance degradation has been observed.
That suggests inserting into a table concurrently by multiple processes degrades insertion performance by order of magnitude beyond my expectation.
Strangely the degradation occurs not only on the table but also on others.
Anyway the problem seems to be successfully worked around. 
2021年5月11日火曜日 16:33:52 UTC+9 Shinji Suzuki:
Thank you, David. I'm not sure if the aborted connection is the cause or the result of the slow down or they are unrelated. though I do see isolated connection aborts. As for transaction processing, after starting to see this problem I modified the programs to do inserts in a transaction and the number of data fsync was reduced by half . I expected more reduction but your note reminds me that the reduction is less significant when dealing with bulk inserts.

I got the problem this morning again and I terminated running connections one by one. I think I've tried that before and it did not work but this time the i/o performance has recovered. Now I'm suspecting that having two connections writing massively into a single table triggers this problem, which strangely results in slow down of inserts into other tables as well. I'll serialize the jobs to ensure no simultaneous inserts and see if it makes any difference.  

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/78d795fb-32ee-4ba7-bdf4-ebd0b8f938a1n%40googlegroups.com.

[google-cloud-sql-discuss] Re: Major Google Cloud SQL issue - SQL Cloud unresponsive

Hi Will,

The original issue was reported almost 2 years ago, so we are hardly able to conclude you are currently being affected by the same issue. It will be much better if you could provide more information (symptom, error logs, metric abnormalities, etc) to facilitate further investigation. Thank you.

On Thursday, June 10, 2021 at 6:13:47 PM UTC-4 will....@mcdbeau.me wrote:
This error seems to be back. We started experiencing this on Google Cloud SQL postgresql, on June 4th 20201

On Wednesday, August 21, 2019 at 3:17:33 PM UTC-7 George (Cloud Platform Support) wrote:
Hello Hugues, 

You are right, something on Google's end was not going as expected, which explains your connectivity issues on 7 August. The issue has been fixed meanwhile. You may check Cloud Status Dashboard for such occurrences any time. 

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/3a36853f-832a-4bb2-860d-9363556d9732n%40googlegroups.com.

Thursday, June 10, 2021

[google-cloud-sql-discuss] Re: Major Google Cloud SQL issue - SQL Cloud unresponsive

This error seems to be back. We started experiencing this on Google Cloud SQL postgresql, on June 4th 20201

On Wednesday, August 21, 2019 at 3:17:33 PM UTC-7 George (Cloud Platform Support) wrote:
Hello Hugues, 

You are right, something on Google's end was not going as expected, which explains your connectivity issues on 7 August. The issue has been fixed meanwhile. You may check Cloud Status Dashboard for such occurrences any time. 

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/16b2ef9d-259c-4905-b552-b991202b6633n%40googlegroups.com.

Thursday, June 3, 2021

[google-cloud-sql-discuss] Re: The write SQL is always running

You can check your instance's flags settings, as some of them can increase the writes, for example [1].


Also, in case you haven't already, enabling the data access audit logs [2] can help you see who is doing these writes to the database so you can take the necessary steps to stop the writes.



[1]: https://cloud.google.com/sql/docs/mysql/flags#:~:text=sync_binlog

[2]: https://cloud.google.com/logging/docs/audit/configure-data-access#enabling-one-service

On Thursday, June 3, 2021 at 9:27:58 AM UTC+2 Ted Gong wrote:
This page said internally cloudsql reverses up to 6 connections. Maybe they are doing something with that? 
1Cloud SQL for PostgreSQL reserves up to six of these connections for internal operations.
https://cloud.google.com/sql/docs/quotas#:~:text=Cloud%20Run%20services%20are%20limited,connections%20per%20deployment%20can%20grow.
On Wednesday, June 2, 2021 at 3:04:20 AM UTC-7 Nobuhito wrote:
Hello, 

When I checked the details of Cloud SQL, the SQL for writing was always executed, and the storage was increasing steadily.
The SQL for writing seems to be running all the time, even though I haven't sent any SQL queries.

What is the SQL for this write?
How can I stop it?

I also contacted customer support in Japan, but they couldn't solve it.

Best regards,

Nobuhito

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/963d7bb0-2128-4f58-9031-9791ff64d561n%40googlegroups.com.

Wednesday, June 2, 2021

[google-cloud-sql-discuss] Re: The write SQL is always running

This page said internally cloudsql reverses up to 6 connections. Maybe they are doing something with that? 
1Cloud SQL for PostgreSQL reserves up to six of these connections for internal operations.
https://cloud.google.com/sql/docs/quotas#:~:text=Cloud%20Run%20services%20are%20limited,connections%20per%20deployment%20can%20grow.
On Wednesday, June 2, 2021 at 3:04:20 AM UTC-7 Nobuhito wrote:
Hello, 

When I checked the details of Cloud SQL, the SQL for writing was always executed, and the storage was increasing steadily.
The SQL for writing seems to be running all the time, even though I haven't sent any SQL queries.

What is the SQL for this write?
How can I stop it?

I also contacted customer support in Japan, but they couldn't solve it.

Best regards,

Nobuhito

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/07e917b7-4dab-43cc-a574-80ddd159a42fn%40googlegroups.com.

[google-cloud-sql-discuss] The write SQL is always running

Hello, 

When I checked the details of Cloud SQL, the SQL for writing was always executed, and the storage was increasing steadily.
The SQL for writing seems to be running all the time, even though I haven't sent any SQL queries.

What is the SQL for this write?
How can I stop it?

I also contacted customer support in Japan, but they couldn't solve it.

Best regards,

Nobuhito

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/3de1dbbd-93e7-44a8-a80c-7184a1d3884cn%40googlegroups.com.

[google-cloud-sql-discuss] Re: Upgrading Postgres from 9.6 to 13

I have not been able to find a way to keep the IP as an upgrade of the Postgres version requires you to create a new Cloud SQL instance [1] and there is no way to assign an IP to it. 


An option to prevent this situation is to use the Cloud SQL Auth proxy [2]. Using it will avoid the need of connecting to the instance using a static IP



[1]: https://cloud.google.com/sql/docs/postgres/upgrade-db

[2]: https://cloud.google.com/sql/docs/postgres/sql-proxy#what_the_provides

On Tuesday, June 1, 2021 at 9:05:25 AM UTC+2 bogu...@gmail.com wrote:
I'd like to be able to upgrade my existing cloudsql postgres 9.6 instance to 11 to use some new pg 11 features.


I need to keep the same IP as the instance with 9.6. There are many applications.

I accept suggestion of less important strategies.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/61e27a90-0792-453c-b12f-85a8ac188ad4n%40googlegroups.com.