Skip site navigation (1) Skip section navigation (2)

Re: [BUGS] BUG #1466: #maintenace_work_mem = 16384

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Joe Brown" <joebrown(at)rclooke(dot)com>,"PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [BUGS] BUG #1466: #maintenace_work_mem = 16384
Date: 2005-02-13 18:27:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
>> What do you think of the following as a fix?
>I dislike going through write_stderr because it requires an extra,
>useless gettext() call,

It does? Isn't already "gettextified"? write_stderr just calls
vfprintf. Or is this an example of me not knowing how gettext works?

> and because in the Windows case it imposes
> an arbitrary length limit that is certain to be exceeded.
>  The length
>limit is probably OK for the existing limited usages of write_stderr,
>but you can't assume that every log message the system ever prints
>is going to be under 2K.

We're not assuming that!
If the system is configured to log to eventlog, this code is never
If the system is configured to log to a file (redirect_stderr), this
code is never called.

It is *only* called when:
- System has not read it's full configuration yet (which is the case we
are trying to address)
- System is configured for logging to stderr *without* capturing it to a
file *and* running as a service. I'd argue this is a configuration

>The proposed test on Redirect_stderr looks pretty fishy too; for one
>thing it will almost certainly not be the right thing inside the stderr
>logger subprocess itself.

Could you explain further what the issue is there? 

There is special code in the send_message_to_server_log function to make
sure it's written directly to the file.



pgsql-patches by date

Next:From: Tom LaneDate: 2005-02-13 19:00:06
Subject: Re: [BUGS] BUG #1466: #maintenace_work_mem = 16384
Previous:From: Tom LaneDate: 2005-02-13 18:04:15
Subject: Re: [BUGS] BUG #1466: #maintenace_work_mem = 16384

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group