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: "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org>,"Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>
Subject: Re: [BUGS] BUG #1466: #maintenace_work_mem = 16384
Date: 2005-02-20 19:13:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
>>> 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? 
>Inside the logger subprocess, Redirect_stderr is guaranteed true (since
>it'll be inherited from the postmaster) and therefore the proposed
>change ensures that anything the logger might want to complain about
>goes to the original stderr, ie, into the bit bucket rather than
>someplace useful.  Perhaps something like
>	if ((!Redirect_stderr || am_syslogger) && pgwin32_is_service())
>would be reasonable.

<snip lots of others>

Here is an updated patch, that should take care of this. Tested that it
solves the problem reported.

>> There is special code in the send_message_to_server_log 
>function to make
>> sure it's written directly to the file.
>If the logger is complaining, it's quite possibly because it's 
>unable to
>write to its file.  Now that you mention it, doesn't this code go into
>infinite recursion if write_syslogger_file_binary() tries to ereport?

I haven't looked at this part, it appears a separate (but closely
related) issue.

Perhaps Andreas can comment on this?


Attachment: stderr.patch
Description: application/octet-stream (1.0 KB)


pgsql-patches by date

Next:From: David FetterDate: 2005-02-20 20:54:44
Subject: Change < to -f in examples with input files
Previous:From: Magnus HaganderDate: 2005-02-20 18:56:10
Subject: pg_ctl reference page

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