On Mon, Apr 08, 2024 at 05:42:05PM +0000, Leung, Anthony wrote: > Are you suggesting that we check if the backend is B_AUTOVAC in > pg_cancel/ terminate_backend? That seems a bit unclean to me since > pg_cancel_backend & pg_cancel_backend does not access to the > procNumber to check the type of the backend. > > IMHO, we can keep SIGNAL_BACKEND_NOAUTOVACUUM but just improve the > errmsg / errdetail to not expose that the backend is an AV > worker. It'll also be helpful if you can suggest what errdetail we > should use here.
The thing is that you cannot rely on a lookup of the backend type for the error information, or you open yourself to letting the caller of pg_cancel_backend or pg_terminate_backend know if a backend is controlled by a superuser or if a backend is an autovacuum worker. And they may have no access to this information by default, except if the role is a member of pg_read_all_stats able to scan pg_stat_activity. An option that I can think of, even if it is not the most elegant ever, would be list all the possible system users that can be used in the errdetail under a single SIGNAL_BACKEND_NO* state. In the case of your patch it would mean to mention both pg_signal_backend and pg_signal_autovacuum. The choice of pg_signal_autovacuum is a bit inconsistent, as well, because autovacuum workers operate like regular backends. This name can also be confused with the autovacuum launcher. -- Michael
signature.asc
Description: PGP signature
