Re: "No transaction in progress" warning

From: Conrad Lender <crlender(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Scott Mead <scott(dot)lists(at)enterprisedb(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: "No transaction in progress" warning
Date: 2009-05-08 14:43:17
Message-ID: 4A044505.1080908@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 07/05/09 18:26, Tom Lane wrote:
> Scott Mead <scott(dot)lists(at)enterprisedb(dot)com> writes:
>> How did you restart postgres? I'm guessing that you're using a
>> distribution provided package. If you're using the /etc/init.d
>> scripts from that package, it's likely that the startup script is
>> redirecting stderr and that the system is configured to use syslog
>> for the rest of the logging.
>
> Right. There are a number of messages that can appear at startup
> before the postmaster reads and adopts the "where to log" settings in
> postgresql.conf. Those early messages are going to go to
> postmaster's stderr. What it sounds like is you're using a start
> script that points postmaster stderr to
> /var/log/postgresql/postgresql-8.3-main.log. I don't find that to be
> a tremendously good idea --- in my RPMs the early-startup messages go
> to a fixed file (/var/lib/pgsql/pgstartup.log) that's not dependent
> on what the "where to log" configuration settings are.

I looked into the startup scripts that are used here (Ubuntu 8.10): the
/etc/init.d script calls a Perl script and redirects that command's
stderr to stdin to capture warnings and errors:

ERRMSG=$(pg_ctlcluster 8.3 main start 2>&1)

The pg_ctlcluster script parses postgresql.conf and, if log_filename and
log_directory aren't defined there, adds '-l
/var/log/postgresql/postgresql-8.3-main.log' as an option for pg_ctl.
This file is created with the appropriate permissions if necessary.
The script then forks, and the child detaches itself from the terminal
and redirects stdout and stderr to /dev/null:

setsid;
dup2(POSIX::open('/dev/null', POSIX::O_WRONLY), 1);
dup2(POSIX::open('/dev/null', POSIX::O_WRONLY), 2);
exec $pg_ctl @options;

That doesn't look too bad to me, or at least it's how I would write a
daemon script, too. If I understand you correctly, stderr should be left
intact?

If this is not the preferred way to handle logging with Postgres, maybe
I should ask pg_ctlcluster's maintainer about it.

Regards,
- Conrad

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bill Moran 2009-05-08 14:45:13 Re: Remote access
Previous Message George Weaver 2009-05-08 14:37:19 Re: Remote access