date:20090914

Re: [HACKERS] Why does LOG have higher priority than ERROR and WARNING?

2009-09-14 Thread Peter Eisentraut

On Mon, 2009-09-14 at 09:16 +0900, Itagaki Takahiro wrote:
 Another matter is that we use LOG level both cases of important
 activity logging and mere performance or query logging. Maybe
 we should have used another log level (PERFORMANCE?) for the
 latter case, and its priority is less than WARNINGs and LOGs.

Ideally, LOG messages are messages that you explicitly requested using
various log_* parameters.  If you need more control, we could
conceivably add more of those.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Elementary dependency look-up

2009-09-14 Thread Greg Smith


On Wed, 9 Sep 2009, decibel wrote:

What might be more useful is a view that takes the guesswork out of using 
pg_depend. Namely, convert (ref)classid into a catalog table name (or better 
yet, what type of object it is), (ref)objid into an actual object name, and 
(ref)objsubid into a real name.


Here's V1 of a depend unraveler I needed recently and that's saved me a 
bunch of time:


SELECT
  c1.oid as relid,
  n1.nspname || '.' || c1.relname as relation,
  c1.relkind,
  CASE
WHEN c1.relkind='r' THEN 'table'
WHEN c1.relkind='i' THEN 'index'
WHEN c1.relkind='S' THEN 'sequence'
WHEN c1.relkind='v' THEN 'view'
WHEN c1.relkind='c' THEN 'composite'
WHEN c1.relkind='t' THEN 'TOAST'
ELSE '?'
  END as kind,
  c2.oid as relid,
  n2.nspname || '.' || c2.relname as dependency,
  c2.relkind,
  CASE
WHEN c2.relkind='r' THEN 'table'
WHEN c2.relkind='i' THEN 'index'
WHEN c2.relkind='S' THEN 'sequence'
WHEN c2.relkind='v' THEN 'view'
WHEN c2.relkind='c' THEN 'composite'
WHEN c2.relkind='t' THEN 'TOAST'
ELSE '?'
  END as kind
FROM
  pg_depend d,
  pg_class c1,
  pg_namespace n1,
  pg_class c2,
  pg_namespace n2
WHERE
  d.objid = c1.oid AND
  c1.relnamespace = n1.oid AND
  n1.nspname NOT IN('information_schema', 'pg_catalog') AND
  n1.nspname !~ '^pg_toast' AND

  d.refobjid = c2.oid AND
  c2.relnamespace = n2.oid AND
  n2.nspname NOT IN('information_schema', 'pg_catalog') AND
  n2.nspname !~ '^pg_toast' AND

  c1.oid != c2.oid

GROUP BY n1.nspname,c1.relname,c1.oid,c1.relkind,
 n2.nspname,c2.relname,c2.oid,c2.relkind
ORDER BY n1.nspname,c1.relname;

I could throw this on the Wiki as a code snippet if anyone else wanted to 
tinker with it.


--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Why does LOG have higher priority than ERROR and WARNING?

2009-09-14 Thread Magnus Hagander

On Mon, Sep 14, 2009 at 02:16, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:

 Tom Lane t...@sss.pgh.pa.us wrote:

 Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
  Can I reorder them to ERROR  WARNING  LOG ?

 No.  That was an intentional decision.  LOG is for stuff that we
 really want to get logged, in most cases.  ERROR is very often not
 that interesting, and WARNING even more so.

 I think the decision is in hacker's viewpoint. Many times I see
 DBAs are interested in only WARNING, ERROR and FATAL, but often
 ignores LOG messages. We should use WARNING level for really important
 message -- and also priority of WARNINGs should be higher than LOGs.

 Another matter is that we use LOG level both cases of important
 activity logging and mere performance or query logging. Maybe
 we should have used another log level (PERFORMANCE?) for the
 latter case, and its priority is less than WARNINGs and LOGs.

I think the requirement you're talking about is the same one I was
when I said I wanted a logging source thing. Which is basically that
an ERROR log from a user query or stored procedure is often not
interesting at all to the DBA - but it is to the developer. But an
ERROR log from the background writer or a low-level routine is *very*
interesting to the DBA. Basically, the log levels mean completely
different things depending on where they're coming in from.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] syslog_line_prefix

2009-09-14 Thread Magnus Hagander

On Mon, Sep 14, 2009 at 02:43, Itagaki Takahiro
itagaki.takah...@oss.ntt.co.jp wrote:
Here is a patch to add a GUC parameter syslog_line_prefix.
It adds prefixes to syslog and eventlog. We still have
log_line_prefix, that will be used only for stderr logs.

We have a tip that log_line_prefix is not required for syslog
in the documentation, but we'd better to have independent setttings
if we set log_destination to 'stderr, syslog'.

http://developer.postgresql.org/pgdocs/postgres/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT
| Tip: Syslog produces its own time stamp and process ID
| information, so you probably do not want to use those escapes
| if you are logging to syslog.

I'm not sure I like this as a GUC. We're going to end up with a lot of
different GUCs, and everytime we add a new log destination (admittedly
not often, of course), that increases even further. And GUCs really
don't provide the level of flexibility you'd really like to have. I've
been thinking (long-term) in the direction of a separate config file,
since that could contain an arbitrary number of lines, with rules on
them (somewhat like pg_hba.conf maybe). You'd do the matching on
things like error level and destination, and then specify a bunch of
flags. Or potentially do it on error level and contents, and filtering
which destinations get it.

Forcing it into the guc framework seems like a limiting long-term strategy.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

97 matches

Mail list logo