| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stanislav Bashkyrtsev <stanislav(dot)bashkirtsev(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: PostgreSQL stops when adding a breakpoint in CLion |
| Date: | 2022-01-03 22:02:43 |
| Message-ID: | 3912337.1641247363@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stanislav Bashkyrtsev <stanislav(dot)bashkirtsev(at)gmail(dot)com> writes:
>> Why do you think postgres quits?
> The process was running and then it stopped. And in the console I see:
> 2022-01-03 23:23:29.495 MSK [76717] LOG: checkpoint starting: shutdown
> immediate
In a standalone backend, I think there are only 3 ways to get to
normal shutdown:
* SIGTERM
* SIGQUIT
* EOF on stdin
It's not very clear which of those your setup is triggering.
In any case, debugging standalone mode is very very rarely
what you should be doing; it's only vaguely related to normal
operation, plus you lack all the creature comforts of psql.
The usual thing is to start a normal interactive session, find out
the PID of its connected backend process ("select pg_backend_pid()"
is a reliable way), and then attach to that process with GDB or your
debugger of choice.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2022-01-03 22:08:05 | Re: CREATEROLE and role ownership hierarchies |
| Previous Message | Tom Lane | 2022-01-03 21:50:43 | Proposal: remove obsolete hot-standby testing infrastructure |