Martin Pihlak writes:
> Thanks, somehow I missed that we can already specify octal integers
> as GUC-s. I now converted the log_file_mode to integer and dropped
> the assign_log_file_mode function.
Applied with a few corrections. The noncosmetic changes were:
* prevent Log_file_mode from disabl
Tom Lane wrote:
> Itagaki Takahiro writes:
>> ...
>> We should also check the value not to be something like 0699.
>> How about checking it with (file_mode & ~0666) != 0 ?
>> ...
>> I want show_log_file_mode to print the setting value in octal format.
>
> It seems like a whole lot of lily-gilding
Itagaki Takahiro writes:
> ...
> We should also check the value not to be something like 0699.
> How about checking it with (file_mode & ~0666) != 0 ?
> ...
> I want show_log_file_mode to print the setting value in octal format.
It seems like a whole lot of lily-gilding is going on here. Just ma
Itagaki Takahiro wrote:
> I think the patch is almost ready for committer except the following
> three issues:
>
> 2010/7/13 Fujii Masao :
>>> + if (!*value || *endptr || file_mode < 0 || file_mode > 0777)
>> The sticky bit cannot be set via log_file_mode. Is this intentional?
Yes -- I don't
I think the patch is almost ready for committer except the following
three issues:
2010/7/13 Fujii Masao :
>> + if (!*value || *endptr || file_mode < 0 || file_mode > 0777)
> The sticky bit cannot be set via log_file_mode. Is this intentional?
We should also check the value not to be somethin
On Mon, Jul 12, 2010 at 7:36 PM, Martin Pihlak wrote:
> Itagaki Takahiro wrote:
>> I checked "log_file_mode GUC" patch, and found a couple of Windows-specific
>> and translation issues.
>
> Thank you for the review. Attached patch attempts to fix these issues.
> + if (!*value || *endptr || fi
Itagaki Takahiro wrote:
> I checked "log_file_mode GUC" patch, and found a couple of Windows-specific
> and translation issues.
Thank you for the review. Attached patch attempts to fix these issues.
> * fchmod() is not available on some platforms, including Windows.
> fh = fopen(filename, mod
I checked "log_file_mode GUC" patch, and found a couple of Windows-specific
and translation issues.
* fchmod() is not available on some platforms, including Windows.
fh = fopen(filename, mode);
setvbuf(fh, NULL, LBF_MODE, 0);
fchmod(fileno(fh), Log_file_mode);
I think umask()->fopen()
Martin Pihlak wrote:
> Attached is a patch that adds a GUC "log_file_mode" which allows to specify
> the creation mode for the log files. Presently it lacks documentation, which
> I'll add if the idea is generally acceptable.
>
Updated patch attached.
regards,
Martin
*** a/doc/src/sgml/config.s
On Thu, Jul 1, 2010 at 12:19 PM, Michael Tharp
wrote:
> That said, as Martin mentions one can easily place the log directory outside
> of the data directory and set appropriate directory permissions.
If I can offer my $0.02, I recently solved such a problem on SuSE
Linux with apache logs. I used
On 07/01/2010 12:56 PM, Kevin Grittner wrote:
I just tried creating a symbolic link to the pg_log directory and
flagging the existing logs within it to 640. As a member of the
group I was able to list and view the contents of log files through
the symbolic link, even though I didn't have any aut
Martin Pihlak writes:
> Tom Lane wrote:
>> It doesn't appear to me that this helps unless you are willing to make
>> the containing director(ies) group-readable/executable as well, which is
>> something we've resisted doing.
> The log can be moved outside of data directory by setting "log_directo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Martin Pihlak writes:
> > It'd be convenient if the log files would have group read access. Then we
> > could
> > make all the DBA or monitoring users members of the postgres group and
> > they'd
> > have direct access to the logs. However, as the "group
Tom Lane wrote:
> It doesn't appear to me that this helps unless you are willing to make
> the containing director(ies) group-readable/executable as well, which is
> something we've resisted doing.
>
The log can be moved outside of data directory by setting "log_directory"
to an absolute path. Th
Tom Lane wrote:
> Martin Pihlak writes:
>> It'd be convenient if the log files would have group read access.
>> Then we could make all the DBA or monitoring users members of the
>> postgres group and they'd have direct access to the logs.
>> However, as the "group read" is not likely a universall
Martin Pihlak writes:
> It'd be convenient if the log files would have group read access. Then we
> could
> make all the DBA or monitoring users members of the postgres group and they'd
> have direct access to the logs. However, as the "group read" is not likely a
> universally correct setting, t
Martin Pihlak wrote:
> Attached is a patch that adds a GUC "log_file_mode" which allows to specify
> the creation mode for the log files. Presently it lacks documentation, which
> I'll add if the idea is generally acceptable.
>
Now it really is attached.
regards,
Martin
*** a/src/backend/comman
With logging_collector enabled, all the postgres log files are created with
mode 0600. This makes life complicated if users other than "postgres" need
to be able to examine the log files as well. Common example of this is when the
database runs under "postgres" user and DBA-s have named accounts.
18 matches
Mail list logo
