Re: proposal: psql: psql variable BACKEND_PID - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: proposal: psql: psql variable BACKEND_PID
Date
Msg-id b68bb584-ce58-4ffc-af5d-639a1d55091d@manitou-mail.org
Whole thread Raw
In response to Re: proposal: psql: psql variable BACKEND_PID  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: proposal: psql: psql variable BACKEND_PID
List pgsql-hackers
    Corey Huinker wrote:

> Manually testing confirms that it works, at least for the connected state. I
> don't actually know how get psql to invoke DISCONNECT, so I killed the dev
> server and can confirm

Maybe something like this could be used, with no external action:

  postgres=# \echo :BACKEND_PID
  10805
  postgres=# create user tester superuser;
  CREATE ROLE
  postgres=# \c postgres tester
  You are now connected to database "postgres" as user "tester".
  postgres=# alter user tester nosuperuser connection limit 0;
  ALTER ROLE
  postgres=# select pg_terminate_backend(pg_backend_pid());
  FATAL:  terminating connection due to administrator command
  server closed the connection unexpectedly
      This probably means the server terminated abnormally
      before or while processing the request.
  The connection to the server was lost. Attempting reset: Failed.
  The connection to the server was lost. Attempting reset: Failed.

  !?> \echo :BACKEND_PID
  :BACKEND_PID


> In the varlistentry, I suggest we add "This variable is unset when the
> connection is lost." after "but can be changed or unset.

Personally I'd much rather have BACKEND_PID set to 0 rather than being unset
when not connected. For one thing it allows safely using \if :BACKEND_PID.


Best regards,
--
Daniel Vérité
https://postgresql.verite.pro/
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Pluggable toaster
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Perform streaming logical transactions by background workers and parallel apply