From: | abbas alizadeh <ramkly(at)yahoo(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Kill postgresql process |
Date: | 2021-06-18 14:33:08 |
Message-ID: | 86429A65-AF41-40D4-8B7C-FDF6E45742A9@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Thanks Laurenz, Julien
Stack trace helps alot to find a stuck point.
That AbortCurrentTransaction wirked as well.
Regards
Abbas
> On 15 Jun 2021, at 3:01 PM, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> On Tue, 2021-06-15 at 00:25 +0800, Julien Rouhaud wrote:
>> Le mar. 15 juin 2021 à 00:15, Laurenz Albe:
>>> - Attach to the backend with gdb.
>>> - Enter "print ProcessInterrupts()"
>>>
>>> Of course that will not work if the backend is in uninterruptible
>>> sleep (for example, stuck in an I/O operation).
>>
>> that may be a terrible idea and leave a buffer pinned or something.
>> and if it's not it won't tell us where we're missing a CALL_FOR_INTERRUPTS
>
> If there is an error, AbortCurrentTransaction() gets called, which releases
> all buffer pins. If you were stuck in an endless loop in a critical
> section, you are going to crash anyway.
>
> If you want to investigate where you are stuck, run a backtrace first.
>
> Yours,
> Laurenz Albe
> --
> Cybertec | https://www.cybertec-postgresql.com
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | still Learner | 2021-06-19 08:40:38 | Re: STDERR not logging after a fix log size |
Previous Message | still Learner | 2021-06-18 13:46:04 | Re: STDERR not logging after a fix log size |