| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | abbas alizadeh <ramkly(at)yahoo(dot)com>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Kill postgresql process |
| Date: | 2021-06-15 07:01:12 |
| Message-ID: | 05a195d0d4fc09c4552551e806fd7692b9804e24.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
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 | Jeff Janes | 2021-06-15 20:20:39 | Re: vacuumdb idle processes |
| Previous Message | Avi Weinberg | 2021-06-15 06:13:51 | Be Notify Upon Streaming Replication Failover |