On Mon, Mar 15, 2021 at 11:23 AM torikoshia <torikos...@oss.nttdata.com> wrote: > > On 2021-03-07 19:16, Bharath Rupireddy wrote: > > On Fri, Feb 5, 2021 at 5:15 PM Bharath Rupireddy > > <bharath.rupireddyforpostg...@gmail.com> wrote: > >> > >> pg_terminate_backend and pg_cancel_backend with postmaster PID produce > >> "PID XXXX is not a PostgresSQL server process" warning [1], which > >> basically implies that the postmaster is not a PostgreSQL process at > >> all. This is a bit misleading because the postmaster is the parent of > >> all PostgreSQL processes. Should we improve the warning message if the > >> given PID is postmasters' PID? > > +1. I felt it was a bit confusing when reviewing a thread[1].
Hmmm. > > I'm attaching a small patch that emits a warning "signalling > > postmaster with PID %d is not allowed" for postmaster and "signalling > > PostgreSQL server process with PID %d is not allowed" for auxiliary > > processes such as checkpointer, background writer, walwriter. > > > > However, for stats collector and sys logger processes, we still get > > "PID XXXXX is not a PostgreSQL server process" warning because they > > don't have PGPROC entries(??). So BackendPidGetProc and > > AuxiliaryPidGetProc will not help and even pg_stat_activity is not > > having these processes' pid. > > I also ran into the same problem while creating a patch in [2]. I have not gone through that thread though. Is there any way we can detect those child processes(stats collector, sys logger) that are forked by the postmaster from a backend process? Thoughts? > I'm now wondering if changing the message to something like > "PID XXXX is not a PostgreSQL backend process". > > "backend process' is now defined as "Process of an instance > which acts on behalf of a client session and handles its > requests." in Appendix. Yeah, that looks good to me. IIUC, we can just change the message from "PID XXXX is not a PostgreSQL server process" to "PID XXXX is not a PostgreSQL backend process" and we don't need look for AuxiliaryProcs or PostmasterPid. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
