Re: [DOCS] Inaccuracy in fe-protocol3.c

On 6/15/16 5:21 AM, Dmitry Igrishin wrote: > Hi, > https://github.com/postgres/postgres/blob/master/src/interfaces/libpq/fe-protocol3.c#L166 > says "ERROR messages are displayed using the notice processor". > But actually "ERROR messages are handled using the notice receiver". Fixed -- Peter

Re: [DOCS] pg_prepared_statements

On 6/3/16 2:38 AM, Dmitry Igrishin wrote: >>> "true if the prepared statement was created via the PREPARE SQL statement" >>> to >>> "true if the prepared statement was created via the PREPARE SQL command" >> >> >> I'm not sure why that is better. "statement" is the standard term in these >>

Re: [DOCS] Need clarification on "another server might be running; trying to start server anyway"

On 7/6/16 4:11 AM, dmigow...@ikoffice.de wrote: > I am currently facing an issue on Servers that are running PostgreSQL 9.5 > started from systemd, and in the case when the Servers power offs the hard > way, and I restart it, I get an error another server might be running; > trying to start server

Re: [DOCS] max_worker_processes default not documented

On 5/12/16 9:24 AM, David G. Johnston wrote: > Thanks. Now for a related question. Are any of those workers > permanently in use? And what processes use them. I can think of > checkpoint writer and autovacuum off the top of my head that are > potential candidates. max_worker_processes only

Re: [DOCS] NOTIFY man page still recommends rules

Alvaro Herrera writes: > Peter Eisentraut wrote: >> Is using rules here still best practice? This was probably written >> before statement triggers were available. > I think it's easier to dodge the rules topic entirely here and just > mention statement triggers.

[DOCS] NOTIFY man page still recommends rules

The NOTIFY man page writes When NOTIFY is used to signal the occurrence of changes to a particular table, a useful programming technique is to put the NOTIFY in a rule that is triggered by table updates. Is using rules here still best practice? This was probably written before