[ADMIN] Built-in log rotation
Greetings! I've been doing some research into log rotation software and ran into this, while looking through the postgres site: "There is a built-in log rotation program, which you can use by setting the configuration parameter redirect_stderr to true in postgresql.conf." http://www.postgresql.org/docs/8.1/interactive/logfile-maintenance.html My question is, how does it rotate logs? Does it perform a copy/truncate of the logfile? I know in older versions of postgres, if you tried to move the log file, and create one with the same name, the server wouldn't actually write to it without a restart...at least in linux it wouldn't. Do many of you use this mechanism? If not, what have you found to be a reliable solution? Thanks in advance for the info! - Kris ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] Built-in log rotation
Kris Kiger wrote: > Greetings! I've been doing some research into log rotation software and > ran into this, while looking through the postgres site: > > "There is a built-in log rotation program, which you can use by setting > the configuration parameter redirect_stderr to true in postgresql.conf." > http://www.postgresql.org/docs/8.1/interactive/logfile-maintenance.html > > My question is, how does it rotate logs? It closes the old file and opens a new one -- new name, new file descriptor, so the problem you mention below doesn't exist anymore. > Does it perform a > copy/truncate of the logfile? I know in older versions of postgres, if > you tried to move the log file, and create one with the same name, the > server wouldn't actually write to it without a restart...at least in > linux it wouldn't. This code is "new" (only two years old). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[ADMIN] log_duration?
I toggle log_duration:
wiki=# \!date
Mon Feb 19 11:14:35 EST 2007
wiki=# set log_duration=off;
SET
wiki=# SELECT current_setting('log_duration');
current_setting
-
off
(1 row)
yet duration continues to be logged:
wiki,13190,wiki,2007-02-19 11:16:00.926 EST,45d94f9e.3386,36108,2007-02-19
02:19:58 EST,270828,BIND LOG: duration: 0.034 ms
wiki,13190,wiki,2007-02-19 11:16:00.929 EST,45d94f9e.3386,36109,2007-02-19
02:19:58 EST,0,COMMIT LOG: duration: 2.840 ms
do I have to bounce to get it set? Thx.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] log_duration?
Ray Stell wrote:
I toggle log_duration:
wiki=# \!date
Mon Feb 19 11:14:35 EST 2007
wiki=# set log_duration=off;
SET
wiki=# SELECT current_setting('log_duration');
current_setting
-
off
(1 row)
yet duration continues to be logged:
wiki,13190,wiki,2007-02-19 11:16:00.926 EST,45d94f9e.3386,36108,2007-02-19
02:19:58 EST,270828,BIND LOG: duration: 0.034 ms
wiki,13190,wiki,2007-02-19 11:16:00.929 EST,45d94f9e.3386,36109,2007-02-19
02:19:58 EST,0,COMMIT LOG: duration: 2.840 ms
do I have to bounce to get it set? Thx.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
!DSPAM:37,45d9d01c18514452914812!
Probably best to restart Postgres, yes. I've observed logging functions
to not take effect without a restart.
Andy.
[ADMIN] grant model in PostgreSQL 8.2
Dear colleagues, What is the preferred grant model in multi-developers environment? I'm currently thinking of two groups, one is 'admin' and other is 'user', where real developers are members of the first group, with 'set role to admin' in pg_authid; report create user (used in web frontend, e.g.) is a member of the second group, having only read privileges from db objects. The question is: can I automatically grant read privileges on newly created objects in my schema? Thanks. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[ADMIN] dst 2007?
Is your database ready for the Daylight Savings Times change of 2007? http://people.planetpostgresql.org/greg/index.php?/archives/96-Is-your-database-ready-for-the-Daylight-Savings-Times-change-of-2007.html in the pg share dir: $ /usr/sbin/zdump -v EST5EDT | grep 2007 EST5EDT Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000 EST5EDT Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400 EST5EDT Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000 Nice to see it in b&w on the system of interest. Thx, Greg. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] dst 2007?
On Mon, Feb 19, 2007 at 03:06:32PM -0500, Ray Stell wrote: > in the pg share dir: > > $ /usr/sbin/zdump -v EST5EDT | grep 2007 On many platforms, regardless of what directory you're in, the above command will read timezone files from a standard directory like /usr/share/zoneinfo, not from the current directory. Even a relative path like ./EST5EDT won't work; you'll need to give the full path: zdump -v /full/path/EST5EDT I'd suggest doing a process trace (ktrace, strace, truss, etc.) to check what timezone file zdump is reading. And if your system stores its local timezone in /etc/localtime, don't forget to check that file as well -- otherwise you might discover that your system uses the correct DST dates for every timezone except the one you're in. -- Michael Fuhr ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [ADMIN] log_duration?
Ray Stell <[EMAIL PROTECTED]> writes: > I toggle log_duration: > wiki=# \!date > Mon Feb 19 11:14:35 EST 2007 > wiki=# set log_duration=off; > SET SET only affects your own session, not anyone else's ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
