Обсуждение: 8.3 RC1 - Logging and filenames

Hi,

I'm just trying out the RC1 release of 8.3, and I'm seeing something strange with the logging configuration.
What I want PostgreSQL to do is put a log file "postgresql.log" in "/var/log/pgsql" - I have an application that handles log rotations, so would prefer to do it with that, rather than have PostgreSQL do the rotation.

I would have thought my config shown below would have made this happen, but it doesn't appear so.  Instead PostgreSQL creates a file called "postgresql.log.1200003749" in /var/log/pgsql.

Best of it is, I cannot work out what those numbers mean.  The time at which PostgreSQL was started was 22:37 on 10th Jan 2008.  So I can figure out that "3749" is probably the minutes and seconds.  The process IDs are in the 32,200s so it's not the PID either.

Is this a bug, or am I just missing something?

My postgresql.conf reads:

# - Where to Log -

log_destination = 'stderr'              # Valid values are combinations of
                                        # stderr, csvlog, syslog and eventlog,
                                        # depending on platform.  csvlog
                                        # requires logging_collector to be on.

# This is used when logging to stderr:
logging_collector = on          # Enable capturing of stderr and csvlog
                                        # into log files. Required to be on for
                                        # csvlogs.
                                        # (change requires restart)

# These are only used if logging_collector is on:
log_directory = '/var/log/pgsql'                # directory where log files are written,
                                        # can be absolute or relative to PGDATA
log_filename = 'postgresql.log ' # log file name pattern,
                                        # can include strftime() escapes
#log_truncate_on_rotation = off         # If on, an existing log file of the
                                        # same name as the new log file will be
                                        # truncated rather than appended to.
                                        # But such truncation only occurs on
                                        # time-driven rotation, not on restarts
                                        # or size-driven rotation.  Default is
                                        # off, meaning append to existing files
                                        # in all cases.
log_rotation_age = 0                    # Automatic rotation of logfiles will
                                        # happen after that time.  0 to disable.
log_rotation_size = 0           # Automatic rotation of logfiles will


Regards,

Andy

"Andy Shellam" <andy.shellam-lists@mailnetwork.co.uk> writes:
> What I want PostgreSQL to do is put a log file "postgresql.log" in
> "/var/log/pgsql" - I have an application that handles log rotations, so
> would prefer to do it with that, rather than have PostgreSQL do the
> rotation.

You don't really have any choice about the matter --- Postgres will not
use a single fixed filename because that would be guaranteed to lose log
entries across a rotation.

> I would have thought my config shown below would have made this happen, but
> it doesn't appear so.  Instead PostgreSQL creates a file called "
> postgresql.log.1200003749" in /var/log/pgsql.

> Best of it is, I cannot work out what those numbers mean.

Per the documentation, Postgres appends the Unix epoch of the file's
creation time if the given pattern hasn't got any %-escapes.
Looks like that corresponds to Thu Jan 10 2008, 17:22:29 EST.

            regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 10 Jan 2008 19:08:57 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Andy Shellam" <andy.shellam-lists@mailnetwork.co.uk> writes:
> > What I want PostgreSQL to do is put a log file "postgresql.log" in
> > "/var/log/pgsql" - I have an application that handles log
> > rotations, so would prefer to do it with that, rather than have
> > PostgreSQL do the rotation.
> 
> You don't really have any choice about the matter --- Postgres will
> not use a single fixed filename because that would be guaranteed to
> lose log entries across a rotation.

Unless he is using syslog?

Joshua D. Drake



- -- 
The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ 
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD'


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhrbjATb/zqfZUUQRAkN+AKCY+dQ9+zExF5Yx9BST22hgxVUzMQCdFqZd
0fqVMpSh9pGkLqeDvG+LTL8=
=XsVx
-----END PGP SIGNATURE-----

"Joshua D. Drake" <jd@commandprompt.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You don't really have any choice about the matter --- Postgres will
>> not use a single fixed filename because that would be guaranteed to
>> lose log entries across a rotation.

> Unless he is using syslog?

True, if you really dislike the way that the built-in log collector
works, syslog is probably your best alternative.

            regards, tom lane

Hi all,

But surely if the rotation is disabled, PostgreSQL will just append to the log if it exists (hence the extra option of "truncate on rotation?")

Many services use a single log file and just keep adding to it - that's the way I'd prefer to set PostgreSQL up, simply so I can predict what the log file's name is.  Our rotation system will then rotate the log and keep the name in the same format as all our other services.

Andy

"Andy Shellam" <andy.shellam-lists@mailnetwork.co.uk> writes:
> Many services use a single log file and just keep adding to it - that's the
> way I'd prefer to set PostgreSQL up, simply so I can predict what the log
> file's name is.  Our rotation system will then rotate the log and keep the
> name in the same format as all our other services.

I wonder exactly how your rotation system is going to accomplish that.
PG doesn't support re-opening its logfile on SIGHUP (and even if it did,
you'd have to find and SIGHUP all the relevant processes ... at the same
time ...)

            regards, tom lane