Обсуждение: Re: [ADMIN] Syslog

Поиск
Список
Период
Сортировка

Re: [ADMIN] Syslog

От
Jie Liang
Дата:
I did, it didn't work.

Jie Liang

-----Original Message-----
From: Joe Conway [mailto:mail@joeconway.com]
Sent: Thursday, March 14, 2002 10:49 AM
To: Jie Liang
Cc: 'pgsql-admin@postgresql.org'; pgsql-sql
Subject: Re: [ADMIN] Syslog


Jie Liang wrote:
> In postgresql.conf:
> #  Syslog
> # requires ENABLE_SYSLOG
> How to do it?
> My OS is FreeBSD4.5
> I installed Postgres-7.2
>
>
> Urgent!!!!!!!!!
>

I think you need to make sure that PostgreSQL was built with
--enable-syslog during configure.

Joe



Re: [ADMIN] Syslog

От
Joe Conway
Дата:
Jie Liang wrote:
> I did, it didn't work.
>
> Jie Liang

Works for me. Did you change postgresql.conf? Here's what mine looks like.

#
#       Syslog
#
# requires ENABLE_SYSLOG
syslog = 1                      # range 0-2
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'

 From the online docs:
SYSLOG (integer)

     PostgreSQL allows the use of syslog for logging. If this option is
set to 1, messages go both to syslog and the standard output. A setting
of 2 sends output only to syslog. (Some messages will still go to the
standard output/error.) The default is 0, which means syslog is off.
This option must be set at server start.

     To use syslog, the build of PostgreSQL must be configured with the
--enable-syslog option.


See:
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/runtime-config.html

Joe



Rules/Trigges Trade-offs

От
Jean-Luc Lachance
Дата:
Hi all!

Is there a guideline on the use of rules compared to triggers when both
can be use to achieve the same result?

JLL


Re: Rules/Trigges Trade-offs

От
Richard Huxton
Дата:
On Friday 06 Dec 2002 4:03 pm, Jean-Luc Lachance wrote:
> Hi all!
>
> Is there a guideline on the use of rules compared to triggers when both
> can be use to achieve the same result?

If I can use rules I do. Rules rewrite the query so are processed once,
whereas triggers get processed for every row.
--  Richard Huxton


Re: Rules/Trigges Trade-offs

От
Bruce Momjian
Дата:
My book has a section on that:
http://www.postgresql.org/docs/awbook.html

Triggers are mostly for testing/modifying the row being
inserted/updated, while rules are better for affecting other rows or
other tables.


Jean-Luc Lachance wrote:
> Hi all!
> 
> Is there a guideline on the use of rules compared to triggers when both
> can be use to achieve the same result?
> 
> JLL
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Rules/Trigges Trade-offs

От
Jean-Luc Lachance
Дата:
Thanks for the info.

Do you mean that if an update affects more than one row I should use
triggers because the rules will be executed only once?

JLL


Richard Huxton wrote:
> 
> On Friday 06 Dec 2002 4:03 pm, Jean-Luc Lachance wrote:
> > Hi all!
> >
> > Is there a guideline on the use of rules compared to triggers when both
> > can be use to achieve the same result?
> 
> If I can use rules I do. Rules rewrite the query so are processed once,
> whereas triggers get processed for every row.
> --
>   Richard Huxton


Re: Rules/Trigges Trade-offs

От
Bruce Momjian
Дата:
No, the rule will affect all the rows using one query.

---------------------------------------------------------------------------

Jean-Luc Lachance wrote:
> Thanks for the info.
> 
> Do you mean that if an update affects more than one row I should use
> triggers because the rules will be executed only once?
> 
> JLL
> 
> 
> Richard Huxton wrote:
> > 
> > On Friday 06 Dec 2002 4:03 pm, Jean-Luc Lachance wrote:
> > > Hi all!
> > >
> > > Is there a guideline on the use of rules compared to triggers when both
> > > can be use to achieve the same result?
> > 
> > If I can use rules I do. Rules rewrite the query so are processed once,
> > whereas triggers get processed for every row.
> > --
> >   Richard Huxton
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Rules/Trigges Trade-offs

От
Josh Berkus
Дата:
Bruce, Richard,

> Triggers are mostly for testing/modifying the row being
> inserted/updated, while rules are better for affecting other rows or
> other tables.

Hmmm.  Thought that there were also some other criteria:

1) Rules can't use indexes to do their processing, so Rules which query large
secondary tables can be a bad idea (maybe this has changed?)

2) Only Rules can "DO INSTEAD"; thus, only Rules are good for defining
Read/Write views.

3) There are no AFTER Rules, making, for example, a rule with a table check on
the new data impractical, so you'd want to use Triggers or Constraints

etc.

There are, IMHO, some things Rules are better for, and some things Triggers
are better for.   I tend to use all Triggers except for updatable views,
simply because using a mix of Rules and Triggers can be very hard to keep
track of, but YMMV.


--
-Josh BerkusAglio Database SolutionsSan Francisco



Re: Rules/Trigges Trade-offs

От
Bruce Momjian
Дата:
Josh Berkus wrote:
> 
> Bruce, Richard,
> 
> > Triggers are mostly for testing/modifying the row being
> > inserted/updated, while rules are better for affecting other rows or
> > other tables.
> 
> Hmmm.  Thought that there were also some other criteria:
> 
> 1) Rules can't use indexes to do their processing, so Rules which query large 
> secondary tables can be a bad idea (maybe this has changed?)

I don't think this is true.  Rewrite is before optimizer so it should be
optimized just the same.

> 
> 2) Only Rules can "DO INSTEAD"; thus, only Rules are good for defining 
> Read/Write views.

True.

> 3) There are no AFTER Rules, making, for example, a rule with a table check on 
> the new data impractical, so you'd want to use Triggers or Constraints

We have changed ordering in 7.3 where I think INSERT rules are _after_
the insert.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Rules/Trigges Trade-offs

От
Josh Berkus
Дата:
Bruce,

> > 1) Rules can't use indexes to do their processing, so Rules which query
large
> > secondary tables can be a bad idea (maybe this has changed?)
>
> I don't think this is true.  Rewrite is before optimizer so it should be
> optimized just the same.

I was speaking if the Rule has to do a lookup on a 2nd table in the course of
its processing; it used to be that such a lookup could not use indexes
because Rules are pre-optimizer.   This could have changed since 7.1, though.

> > 3) There are no AFTER Rules, making, for example, a rule with a table
check on
> > the new data impractical, so you'd want to use Triggers or Constraints
>
> We have changed ordering in 7.3 where I think INSERT rules are _after_
> the insert.

How would that work?  What if I want to reject the insert?


--
-Josh BerkusAglio Database SolutionsSan Francisco



Re: Rules/Trigges Trade-offs

От
Bruce Momjian
Дата:
Josh Berkus wrote:
> 
> Bruce,
> 
> > > 1) Rules can't use indexes to do their processing, so Rules which query 
> large 
> > > secondary tables can be a bad idea (maybe this has changed?)
> > 
> > I don't think this is true.  Rewrite is before optimizer so it should be
> > optimized just the same.
> 
> I was speaking if the Rule has to do a lookup on a 2nd table in the course of 
> its processing; it used to be that such a lookup could not use indexes 
> because Rules are pre-optimizer.   This could have changed since 7.1, though.

As I remember, the RULE is processed just like an ordinary query.  I
wasn't aware it was looking up anything.

> > > 3) There are no AFTER Rules, making, for example, a rule with a table 
> check on 
> > > the new data impractical, so you'd want to use Triggers or Constraints
> > 
> > We have changed ordering in 7.3 where I think INSERT rules are _after_
> > the insert.
> 
> How would that work?  What if I want to reject the insert?

Uh, good question.  I can't remember now what we re-ordered in 7.3, but
I thought it had to do with rules.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Rules/Trigges Trade-offs

От
Bruce Momjian
Дата:
Bruce Momjian wrote:
> > > > 3) There are no AFTER Rules, making, for example, a rule with a table 
> > check on 
> > > > the new data impractical, so you'd want to use Triggers or Constraints
> > > 
> > > We have changed ordering in 7.3 where I think INSERT rules are _after_
> > > the insert.
> > 
> > How would that work?  What if I want to reject the insert?
> 
> Uh, good question.  I can't remember now what we re-ordered in 7.3, but
> I thought it had to do with rules.

OK, I found what I wanted. We made rules fire in alphabetical order in
7.3, and INSTEAD rules are not reordered to the font/back --- they are
treated just like any other rule and executed alphabetically.

I thought we had some problem with rules or triggers and OLD/NEW
handling, but I can't see any mention of that, and it must have been in
an older release.

The question of firing order is a good one and one that isn't asked very
often.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


Re: Rules/Trigges Trade-offs

От
Jean-Luc Lachance
Дата:
Josh,

Thanks for the info.  

I need to change an insert into an update when the key already exists.
I have been using a rules to test it on a small set (table) and it
works.
"Rules can't use indexes" just scared me. I will have to test on a
larger set.
Also, I had the impression that if a trigger returned NULL, one would
get the equivalent of "DO NOTHING".
Am I wrong with that assumption?

JLL


Josh Berkus wrote:
> 
> Bruce, Richard,
> 
> > Triggers are mostly for testing/modifying the row being
> > inserted/updated, while rules are better for affecting other rows or
> > other tables.
> 
> Hmmm.  Thought that there were also some other criteria:
> 
> 1) Rules can't use indexes to do their processing, so Rules which query large
> secondary tables can be a bad idea (maybe this has changed?)
> 
> 2) Only Rules can "DO INSTEAD"; thus, only Rules are good for defining
> Read/Write views.
> 
> 3) There are no AFTER Rules, making, for example, a rule with a table check on
> the new data impractical, so you'd want to use Triggers or Constraints
> 
> etc.
> 
> There are, IMHO, some things Rules are better for, and some things Triggers
> are better for.   I tend to use all Triggers except for updatable views,
> simply because using a mix of Rules and Triggers can be very hard to keep
> track of, but YMMV.
> 
> --
> -Josh Berkus
>  Aglio Database Solutions
>  San Francisco