Re: Additional message in pg_terminate_backend - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Additional message in pg_terminate_backend
Date
Msg-id 99f3524c-6aee-4fe2-8f3f-fcf0b67642c2@uni-muenster.de
Whole thread Raw
In response to Re: Additional message in pg_terminate_backend  (Kirill Reshke <reshkekirill@gmail.com>)
List pgsql-hackers
Hi Roman,

As pointed out by Kirill, there is no reason to create
pg_terminate_backend_msg or pg_cancel_backend_msg. You can simply use
the existing functions and expand them to use one extra parameter, e.g.

CREATE OR REPLACE FUNCTION
  pg_terminate_backend(pid integer, timeout int8 DEFAULT 0, msg text
DEFAULT '')
  RETURNS boolean STRICT VOLATILE LANGUAGE INTERNAL AS
'pg_terminate_backend'
  PARALLEL SAFE;


Here I don't think we need to check PG_NARGS, since the function calls
will always have a default value. Something like this perhaps:


Datum pg_terminate_backend(PG_FUNCTION_ARGS)
{
  int pid;
  int timeout; /* milliseconds */
  char *msg;

  pid = PG_GETARG_INT32(0);
  timeout = PG_GETARG_INT64(1);
  msg = text_to_cstring(PG_GETARG_TEXT_PP(2));

  return pg_terminate_backend_internal(pid, timeout, msg);
}

stpncpy() -> strlcpy()

Documentation is missing -- assuming the feature design is already solid.

Add backend_msg.c to meson.build.

I rebased the patch (it was failing for quite some time) with some
suggestions. Feel free to remove them and revert to your v2 if you disagree.

I'll review the rest of code in the next days.

Best, Jim
Attachment

pgsql-hackers by date:

Previous
From: Nikolay Samokhvalov
Date:
Subject: Re: amcheck: support for GiST
Next
From: Lukas Fittl
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?