Thread: Kill postgresql process

Hi all.
How we can kill the stuck process?
The process didn’t kill by pg_cancel_backend/pg_terminate_backend.
Is there any way beside of using “kill -9” or “pg_ctl kill ABRT” ?

Best regard
Abbas

On Mon, Jun 14, 2021 at 11:41 PM abbas alizadeh <ramkly@yahoo.com> wrote:
>
> How we can kill the stuck process?
> The process didn’t kill by pg_cancel_backend/pg_terminate_backend.
> Is there any way beside of using “kill -9” or “pg_ctl kill ABRT” ?

pg_cancel_backend / pg_terminate_backend is the normal way to do that.
If it's not working it means there's something going on.  Is it a
regular backend, and if yes what query is it executing?

Do you have any 3rd party extensions, and what is the postgres versions?

If could also help to get a stack trace:
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend

On Mon, 2021-06-14 at 23:41 +0800, abbas alizadeh wrote:
> How we can kill the stuck process?
> The process didn’t kill by pg_cancel_backend/pg_terminate_backend.
> Is there any way beside of using “kill -9” or “pg_ctl kill ABRT” ?

If you don't mind a little hackery, I found a simple way to
terminate backends that don't react to interrupts that avoids
"kill -9" and the ensuing crash recovery:

- 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).

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com

The query was called by web server, It was connected to database through socket and connection wasn’t terminate. I
triedto close the connection, but it didn’t work. 
 Postgres version is 9.2 for this case.
We use postgis and pg_repack


> On 14 Jun 2021, at 11:49 PM, Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Mon, Jun 14, 2021 at 11:41 PM abbas alizadeh <ramkly@yahoo.com> wrote:
>>
>> How we can kill the stuck process?
>> The process didn’t kill by pg_cancel_backend/pg_terminate_backend.
>> Is there any way beside of using “kill -9” or “pg_ctl kill ABRT” ?
>
> pg_cancel_backend / pg_terminate_backend is the normal way to do that.
> If it's not working it means there's something going on.  Is it a
> regular backend, and if yes what query is it executing?
>
> Do you have any 3rd party extensions, and what is the postgres versions?
>
> If could also help to get a stack trace:
> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
>
>

On Tue, Jun 15, 2021 at 12:32:40AM +0800, abbas alizadeh wrote:
> The query was called by web server, It was connected to database through
> socket and connection wasn’t terminate. I tried to close the connection, but
> it didn’t work.

Yes, I understand that.  What do you see in pg_stat_activity for the given pid?

Is there any chance you can get a stack trace (with the link previously
provided)?

>  Postgres version is 9.2 for this case.

Which minor version?

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