Обсуждение: Re: [ADMIN] Syslog
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
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
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
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
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
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
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
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
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
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
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
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
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