On Sun, Mar 7, 2021 at 3:46 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Fri, Feb 5, 2021 at 5:15 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@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?
> >
> > If yes, how about a generic message for both of the functions -
> > "signalling postmaster process is not allowed" or "cannot signal
> > postmaster process" or some other better suggestion?
> >
> > [1] 2471176 ---> is postmaster PID.
> > postgres=# select pg_terminate_backend(2471176);
> > WARNING: PID 2471176 is not a PostgreSQL server process
> > pg_terminate_backend
> > ----------------------
> > f
> > (1 row)
> > postgres=# select pg_cancel_backend(2471176);
> > WARNING: PID 2471176 is not a PostgreSQL server process
> > pg_cancel_backend
> > -------------------
> > f
> > (1 row)
>
> 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.
As there is some interest shown in this thread at [1], I'm attaching a
new v3 patch here. Please review it.
CF entry - https://commitfest.postgresql.org/36/3411/
[1] - https://www.postgresql.org/message-id/CAFiTN-sX_66svOPdix1edB_WxGj%3DWu4XouyRQrvySwCK0V8Btg%40mail.gmail.com
Regards,
Bharath Rupireddy.