Re: Unexplained createdb mydb response
PG Doc comments form writes: > I tried the first example in section 1.3 of the initial tutorial, > createdb mydb > The tutorial says >> If this produces no response then this step was successful and you can >> skip over the remainder of this section. Well, it's right --- the normal behavior is to just do it without printing anything: $ createdb mydb $ Or you might get an error: $ createdb mydb createdb: error: database creation failed: ERROR: database "mydb" already exists $ > Well, it produces no response, no response at all. It doesn't even return > control to the shell. I have to use ^C to kill it. That's weird, but I think it's not in-scope for the docs (especially a tutorial) to explain behavior that shouldn't be happening. One idea is that you have a firewall or packet filter blocking the connection attempt. In that case I'd expect createdb to time out and report a connection failure when it gets no response, but the timeout is probably a few minutes ... how long did you wait? Another possibility is that createdb is trying to prompt for a database password but for some reason the "Password:" prompt is not showing up on your terminal. That could be a bug, but I'm not familiar enough with the Cygwin environment to diagnose it. > Any suggestions on what to do would be appreciated. You'd probably be better off asking for help about this on the -novice or -bugs lists than -docs. regards, tom lane
doc: clarify "pg_signal_backend" default role
Hi Currently the documentation for the default role "pg_signal_backend" states, somewhat ambiguously, "Send signals to other backends (eg: cancel query, terminate)", giving the impression other signals (e.g. SIGHUP) can be sent too, which is currently not the case. Attached patch clarifies this, adds a descriptive paragraph (similar to what the other default roles have) and a link to the "Server Signaling Functions" section. Patch applies cleanly to HEAD and REL_11_STABLE. Regards Ian Barwick -- Ian Barwick https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml new file mode 100644 index 6106244..76b6ddb *** a/doc/src/sgml/user-manag.sgml --- b/doc/src/sgml/user-manag.sgml *** DROP ROLE doomed_role; *** 532,538 pg_signal_backend !Send signals to other backends (eg: cancel query, terminate). pg_read_server_files --- 532,538 pg_signal_backend !Signal another backend to cancel a query or terminate the backend. pg_read_server_files *** DROP ROLE doomed_role; *** 561,566 --- 561,573 + The pg_signal_backend role is intended to allow administrators to enable + trusted, but non-superuser, roles to send signals to other backends. Currently this role + enables sending of signals for canceling a query on another backend or terminating the + backend. A user granted this role cannot however send signals to a backend owned by a superuser. + See also . + + The pg_read_server_files, pg_write_server_files and pg_execute_server_program roles are intended to allow administrators to have trusted, but non-superuser, roles which are able to access files and run programs on the
Re: doc: clarify "pg_signal_backend" default role
On Mon, Jun 10, 2019 at 11:06:54AM +0900, Ian Barwick wrote: > Currently the documentation for the default role "pg_signal_backend" states, > somewhat ambiguously, "Send signals to other backends (eg: cancel query, > terminate)", > giving the impression other signals (e.g. SIGHUP) can be sent too, which is > currently not the case. (Perhaps you should avoid cross-posting?) OK, I can see your point. > Attached patch clarifies this, adds a descriptive paragraph (similar to what > the other default roles have) and a link to the "Server Signaling Functions" > section. +1 for being more descriptive here. -- Michael signature.asc Description: PGP signature
