From: | tony(at)exquisiteimages(dot)com |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Analyze command running for 2063 minutes so far |
Date: | 2019-06-28 15:06:03 |
Message-ID: | 1a57237a742b1f9e4cdd0177b8d5983b@exquisiteimages.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2019-06-28 10:15, Tom Lane wrote:
> tony(at)exquisiteimages(dot)com writes:
>> I started an Analyze command on a database Wednesday evening at around
>> 9:00PM. it is now Friday morning at 8:00 and it is still running.
>> ...
>> I did try to execute:
>> SELECT pg_cancel_backend(4029);
>> and
>> SELECT pg_terminate_backend(4029);
>> but neither had any effect.
>
> Hm, that's interesting. Can you get a stack trace from that process?
>
> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
>
>> I am running PostgreSQL version 9.3 on Ubuntu 14.04 with 128GB of
>> memory, 800GB PCIe SSD for Database files, 1TB SATA SSD for WAL, 512GB
>> SATA SSD for system files.
>
> 9.3.what exactly?
>
> (You do know that 9.3.x is out of support, so even if this
> investigation
> reveals a bug, we're not going to fix it in 9.3.x. I'm willing to look
> anyway on the chance that there's a bug that also affects later
> versions.)
>
> regards, tom lane
Thanks for the offer to look at it Tom. Fortunately or unfortunately as
the case may be, after I installed everything to get the stack trace the
Analyze process actually finished. The max(last_analyze) did not change
and is still showing '6/27/2019 8:27 AM', so I am not sure what it was
doing all this time, but nothing seems the worse for it.
Thanks again.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Kumar | 2019-06-28 15:09:51 | how to understand checkpoint information in pg_control data |
Previous Message | Tom Lane | 2019-06-28 14:15:02 | Re: Analyze command running for 2063 minutes so far |