log : bad file dscriptor????

Поиск
Список
Период
Сортировка
От Ati Rosselet
Тема log : bad file dscriptor????
Дата
Msg-id ce6402fc0810250813h67cd7ac9t539974297f037a5b@mail.gmail.com
обсуждение исходный текст
Ответы Re: log : bad file dscriptor????  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Список pgsql-bugs
I'm still getting a lot of these entries in my eventlog whenever I have a
reasonably large amount of logging:

Event Type:    Error
Event Source:    PostgreSQL
Event Category:    None
Event ID:    0
Date:        10/22/2008
Time:        9:36:28 AM
User:        N/A
Computer:    ----------
Description:
could not write to log file: Bad file descriptor

production server 8.3.3 (tried with 8.3.4 - same thing), win 2003 server.
I'd register this as a formal bug, but I can't figure out how to reproduce
it.. and
apparently noone else has seen this?   Or is noone else running postgres on
win2003??? (survey says??)

The timing of each appears to be when log is rolled over (size limited to
10MB) and postgres attempts to write a log entry at the same time:

Any ideas? help? How to proceed???
Cheers
Ati

My log settings from postgresql.conf:

#-----------------------------
-------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------
# - Where to Log -
log_destination = 'stderr'        # Valid values are combinations of
 # This is used when logging to stderr:
logging_collector = on        # Enable capturing of stderr and csvlog

# These are only used if logging_collector is on:
#log_directory = 'pg_log'        # directory where log files are written,
                    # can be absolute or relative to PGDATA
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.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 = 1d            # Automatic rotation of logfiles will
                    # happen after that time.  0 to disable.
log_rotation_size = 10MB        # Automatic rotation of logfiles will
                    # happen after that much log output.
                    # 0 to disable.

# These are relevant when logging to syslog:
#syslog_facility = 'LOCAL0'
#syslog_ident = 'postgres'


# - When to Log -

#client_min_messages = notice        # values in order of decreasing detail:

#log_min_messages = notice        # values in order of decreasing detail:

#log_error_verbosity = default        # terse, default, or verbose messages

#log_min_error_statement = error    # values in order of decreasing detail:
#log_min_duration_statement = -1    # -1 is disabled, 0 logs all statements
                    # and their durations, > 0 logs only
                    # statements running at least this time.

#silent_mode = off            # DO NOT USE without syslog or
                    # logging_collector
                    # (change requires restart)
# - What to Log -

#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = off
#log_checkpoints = off
log_connections = on
log_disconnections = on
#log_duration = off
#log_hostname = off
#log_line_prefix = '%t '            # special values:

log_line_prefix = '%t [%h:%u@%d] '
#log_lock_waits = off            # log lock waits >= deadlock_timeout
log_statement = 'all'            # none, ddl, mod, all
#log_temp_files = -1            # log temporary files equal or larger
                    # than specified size;
                    # -1 disables, 0 logs all temp files
#log_timezone = unknown            # actually, defaults to TZ environment

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Michael Meskes
Дата:
Сообщение: Re: BUG #4493: Memory leak in informix.c
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: cache lookup failed for function 0