message clarifications

On Sat, 2010-04-03 at 11:00 +0300, Peter Eisentraut wrote:

The following messages from the postgres catalog either appear to be
internal errors that should be marked differently, or they are in my
estimation unintelligible to users and should be rephrased.

OK, will look.

--
Simon Riggs www.2ndQuadrant.com

Peter Eisentraut <peter_e@gmx.net> writes:

The following messages from the postgres catalog either appear to be
internal errors that should be marked differently, or they are in my
estimation unintelligible to users and should be rephrased.

#: commands/async.c:1424
msgid "pg_notify queue is %.0f%% full"

This one is probably my responsibility (the others all look like Simon's
code). What do you not like about it, exactly? Perhaps it should be
"NOTIFY queue is x% full"?

regards, tom lane

On Apr 3, 2010, at 11:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

The following messages from the postgres catalog either appear to be
internal errors that should be marked differently, or they are in my
estimation unintelligible to users and should be rephrased.

#: commands/async.c:1424
msgid "pg_notify queue is %.0f%% full"

This one is probably my responsibility (the others all look like
Simon's
code). What do you not like about it, exactly? Perhaps it should be
"NOTIFY queue is x% full"?

I think maybe the question is why the user should care, or what they
are expected to do about it?

...Robert

On Sat, Apr 3, 2010 at 9:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Apr 3, 2010, at 11:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

The following messages from the postgres catalog either appear to be
internal errors that should be marked differently, or they are in my
estimation unintelligible to users and should be rephrased.

#: commands/async.c:1424
msgid "pg_notify queue is %.0f%% full"

This one is probably my responsibility (the others all look like
Simon's
code).  What do you not like about it, exactly?  Perhaps it should be
"NOTIFY queue is x% full"?

I think maybe the question is why the user should care, or what they
are expected to do about it?

The user/administrator should make sure that all backends work through
the list of pending notifications. He does it by making sure that
there are no long-running or idle-in-transaction backends.

Actually there is more information given via errdetail and errhint:

ereport(WARNING,
(errmsg("pg_notify queue is %.0f%% full", fillDegree * 100),
(minPid != InvalidPid ?
errdetail("PID %d is among the slowest backends.", minPid)
: 0),
(minPid != InvalidPid ?
errhint("Cleanup can only proceed if this backend ends its current
transaction.")
: 0)));

Peter, if you consider the additional information given here, do you
still see an issue?

Joachim

Robert Haas <robertmhaas@gmail.com> writes:

On Apr 3, 2010, at 11:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

What do you not like about it, exactly? Perhaps it should be
"NOTIFY queue is x% full"?

I think maybe the question is why the user should care, or what they
are expected to do about it?

The errdetail and errhint that go along with it will perhaps help to
answer that.

regards, tom lane

On lör, 2010-04-03 at 11:13 -0400, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

The following messages from the postgres catalog either appear to be
internal errors that should be marked differently, or they are in my
estimation unintelligible to users and should be rephrased.

#: commands/async.c:1424
msgid "pg_notify queue is %.0f%% full"

This one is probably my responsibility (the others all look like Simon's
code). What do you not like about it, exactly? Perhaps it should be
"NOTIFY queue is x% full"?

Yeah, that plus some hints maybe. "pg_notify" had me confused
initially, since it looks like a system catalog table name.

Peter Eisentraut <peter_e@gmx.net> writes:

On lör, 2010-04-03 at 11:13 -0400, Tom Lane wrote:

This one is probably my responsibility (the others all look like Simon's
code). What do you not like about it, exactly? Perhaps it should be
"NOTIFY queue is x% full"?

Yeah, that plus some hints maybe. "pg_notify" had me confused
initially, since it looks like a system catalog table name.

OK, I did this:

Index: async.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/commands/async.c,v
retrieving revision 1.155
diff -c -r1.155 async.c
*** async.c	26 Feb 2010 02:00:37 -0000	1.155
--- async.c	5 Apr 2010 00:38:03 -0000
***************
*** 1421,1432 ****
  		}

ereport(WARNING,
! (errmsg("pg_notify queue is %.0f%% full", fillDegree * 100),
(minPid != InvalidPid ?
! errdetail("PID %d is among the slowest backends.", minPid)
: 0),
(minPid != InvalidPid ?
! errhint("Cleanup can only proceed if this backend ends its current transaction.")
: 0)));

  		asyncQueueControl->lastQueueFillWarn = t;
--- 1421,1432 ----
  		}

ereport(WARNING,
! (errmsg("NOTIFY queue is %.0f%% full", fillDegree * 100),
(minPid != InvalidPid ?
! errdetail("The server process with PID %d is among those with the oldest transactions.", minPid)
: 0),
(minPid != InvalidPid ?
! errhint("The NOTIFY queue cannot be emptied until that process ends its current transaction.")
: 0)));

asyncQueueControl->lastQueueFillWarn = t;

regards, tom lane

On Sat, 2010-04-03 at 11:00 +0300, Peter Eisentraut wrote:

The following messages from the postgres catalog either appear to be
internal errors that should be marked differently, or they are in my
estimation unintelligible to users and should be rephrased.

#: storage/ipc/procarray.c:2224
msgid "record known xact %u latestObservedXid %u"

#: storage/ipc/procarray.c:2257
msgid "recording unobserved xid %u (latestObservedXid %u)"

#: storage/ipc/procarray.c:2379
msgid "too many KnownAssignedXids"

#: storage/ipc/standby.c:861
msgid ""
"snapshot of %u running transactions overflowed (lsn %X/%X oldest "
"xid %u next xid %u)"

#: storage/ipc/standby.c:868
msgid ""
"snapshot of %u running transaction ids (lsn %X/%X oldest xid %u "
"next xid %u)"

These are all DEBUG messages. Can you explain "marked differently" so I
can do that for you?

--
Simon Riggs www.2ndQuadrant.com

On tis, 2010-04-06 at 10:30 +0100, Simon Riggs wrote:

These are all DEBUG messages. Can you explain "marked differently" so I
can do that for you?

Then it would be better to convert them to use elog() instead of
ereport().

On Tue, 2010-04-06 at 12:44 +0300, Peter Eisentraut wrote:

On tis, 2010-04-06 at 10:30 +0100, Simon Riggs wrote:

These are all DEBUG messages. Can you explain "marked differently" so I
can do that for you?

Then it would be better to convert them to use elog() instead of
ereport().

Will do

--
Simon Riggs www.2ndQuadrant.com

Peter Eisentraut <peter_e@gmx.net> writes:

On tis, 2010-04-06 at 10:30 +0100, Simon Riggs wrote:

These are all DEBUG messages. Can you explain "marked differently" so I
can do that for you?

Then it would be better to convert them to use elog() instead of
ereport().

Or use errmsg_internal instead of errmsg.

regards, tom lane

On Tue, 2010-04-06 at 09:57 -0400, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

On tis, 2010-04-06 at 10:30 +0100, Simon Riggs wrote:

These are all DEBUG messages. Can you explain "marked differently" so I
can do that for you?

Then it would be better to convert them to use elog() instead of
ereport().

Or use errmsg_internal instead of errmsg.

I've changed them to elog() before you said this. Would you like me to
change them to errmsg_internal or do you mean "...as an option in the
future"?

--
Simon Riggs www.2ndQuadrant.com

Simon Riggs <simon@2ndQuadrant.com> writes:

On Tue, 2010-04-06 at 09:57 -0400, Tom Lane wrote:

Or use errmsg_internal instead of errmsg.

I've changed them to elog() before you said this. Would you like me to
change them to errmsg_internal or do you mean "...as an option in the
future"?

It's just a different option. elog for debug messages is a well
established practice, but if you wanted something that looked more
like ereport, you could hide the messages from translation with
the above.

regards, tom lane