Josh Berkus writes:
> This isn't an invented problem; a brief canvass on IRC shows that people
> run into issues with log_collector reloads fairly commonly. However,
> it's pretty low priority, certainly -- never rises above the level of
> "annoyance". The sort of thing where it would be good to
>> On the whole though, I think this is an invented problem. We've never
>> heard a complaint from the field about it.
>
> I think process title seems reasonable. We do that for archiver for
> example, to tell you where it's writing, don't we?
Yes, we do.
This isn't an invented problem; a brie
On Sat, Apr 28, 2012 at 03:35, Tom Lane wrote:
> Josh Berkus writes:
>> You can end up in a situation where the logs aren't going where they're
>> supposed to due to some external problem, and that the DBA has no way to
>> find out what went wrong because he doesn't know where the logs are *now*.
Josh Berkus writes:
> You can end up in a situation where the logs aren't going where they're
> supposed to due to some external problem, and that the DBA has no way to
> find out what went wrong because he doesn't know where the logs are *now*.
Well, if nothing else, lsof would help. Another po
> Well, sorry, but you can't have that. SHOW will tell you what your own
> backend thinks the value of the GUC variable is, but there is no way to
> know what's happening inside the logging collector process. And I'd be
> against trying to add a signaling mechanism that would support telling
> yo
Josh Berkus writes:
> We do have one piece of unituitive behavior here though, which forms a
> bit of a catch-22:
> 1. DBA changes the log directory
> 2. Log directory is unwriteable
> 3. Postgres continues writing to the old log_directory
> 4. SHOW log_directory displays the *new* log_directory
I wrote:
> Mark Kirkwood writes:
>> Might be a red herring, but I was able to reproduce this if (and only
>> if) I forgot to create the new dest directory before doing the reload.
>> Subsequently creating the directory and reloading did not result in a
>> file in the new location.
> Whoever wr
> Whoever wrote that thought that Log_RotationAge/Log_RotationSize would
> get reset to normal values during SIGHUP, but it's far from clear to me
> that any such thing would actually happen. However, this would only
> apply to Josh's problem if he was trying to set a bogus new value of
> log_dir
Mark Kirkwood writes:
> Might be a red herring, but I was able to reproduce this if (and only
> if) I forgot to create the new dest directory before doing the reload.
> Subsequently creating the directory and reloading did not result in a
> file in the new location.
Hmm, interesting point. Th
Josh Berkus writes:
>> Do you want to try attaching to the collector with a debugger and seeing
>> if it ever gets into the "if (got_SIGHUP)" block in SysLoggerMain?
> Hmmm. No debugger on this system, not unexpectedly. I'll see if I can
> get authorization to add one.
How about strace --- if
> Do you want to try attaching to the collector with a debugger and seeing
> if it ever gets into the "if (got_SIGHUP)" block in SysLoggerMain?
Hmmm. No debugger on this system, not unexpectedly. I'll see if I can
get authorization to add one.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pge
On 27/04/12 13:11, Josh Berkus wrote:
On 4/26/12 5:50 PM, Tom Lane wrote:
Josh Berkus writes:
Summary: despite pg_reload(), log directory, filename and destination
don't change
Looking at the code, it's really hard to see how this could possibly
happen, unless maybe the process is blocking re
Josh Berkus writes:
> On 4/26/12 5:50 PM, Tom Lane wrote:
>> check the process's signal masks like this:
>> grep ^Sig /proc//status
>> where is the logging collector's PID. Could we see that?
> SigQ: 0/399360
> SigPnd:
> SigBlk:
> SigIgn: 0100
On 4/26/12 5:50 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Summary: despite pg_reload(), log directory, filename and destination
>> don't change
>
> Looking at the code, it's really hard to see how this could possibly
> happen, unless maybe the process is blocking receipt of SIGHUP. Which
> it
Josh Berkus writes:
> Summary: despite pg_reload(), log directory, filename and destination
> don't change
Looking at the code, it's really hard to see how this could possibly
happen, unless maybe the process is blocking receipt of SIGHUP. Which
it shouldn't be. Not sure about RHEL5, but on rec
Summary: despite pg_reload(), log directory, filename and destination
don't change
Version: 9.1.3
Platform: RHEL5, custom compile
Severity: Persistant annoyance
Description:
1) change log_directory in postgresql.conf
2) pg_reload_conf()
3) show log_directory displays the correct new directory
4)
16 matches
Mail list logo
