On 2025/02/03 19:31, Jim Jones wrote:
Hi Kirill
On 31.01.25 11:46, Kirill Gavrilov wrote:
Sorry for the long silence. I fixed the indentation and a trailing
whitespace. Should look fine now.
The patch applies cleanly, the documentation is clear, and all tests pass.
It is possible to cha
Hi Kirill
On 31.01.25 11:46, Kirill Gavrilov wrote:
> Sorry for the long silence. I fixed the indentation and a trailing
> whitespace. Should look fine now.
The patch applies cleanly, the documentation is clear, and all tests pass.
It is possible to change this new parameter session-wise, whic
On Mon, Dec 2, 2024 at 1:09 PM Jim Jones wrote:
>
>
> On 29.11.24 21:57, Kirill Gavrilov wrote:
> > Same thing applies to log_parameter_max_length, for example.
> >
> > postgres=# set log_parameter_max_length = '1foo';
> > ERROR: invalid value for parameter "log_parameter_max_length": "1foo"
> >
On 29.11.24 21:57, Kirill Gavrilov wrote:
> Same thing applies to log_parameter_max_length, for example.
>
> postgres=# set log_parameter_max_length = '1foo';
> ERROR: invalid value for parameter "log_parameter_max_length": "1foo"
> HINT: Valid units for this parameter are "B", "kB", "MB", "GB
>
>
> Hi
>
> > +for (my $attempts = 0; $attempts < $max_attempts; $attempts++)
> > +{
> > + eval {
> > + $current_logfiles = slurp_file($node->data_dir . '/current_logfiles');
> > + };
> > + last unless $@;
> > + usleep(100_000);
> > +}
>
>
> `usleep` in tap tests is usually a bad pattern. Do we ha
On Sat, 30 Nov 2024 at 01:57, Kirill Gavrilov wrote:
>
> On Fri, Nov 29, 2024 at 10:12 PM Jim Jones wrote:
>>
>>
>>
>> On 29.11.24 12:05, Kirill Gavrilov wrote:
>> > Setting max_log_size to 0 already disables truncation.
>> > I changed guc units to bytes, just to make it more human-friendly.
On Fri, Nov 29, 2024 at 10:12 PM Jim Jones
wrote:
>
>
> On 29.11.24 12:05, Kirill Gavrilov wrote:
> > Setting max_log_size to 0 already disables truncation.
> > I changed guc units to bytes, just to make it more human-friendly.
> > Did some refactoring and fixed all warnings. Set default valu
On 29.11.24 12:05, Kirill Gavrilov wrote:
> Setting max_log_size to 0 already disables truncation.
> I changed guc units to bytes, just to make it more human-friendly.
> Did some refactoring and fixed all warnings. Set default value in
> postgresql.conf.
Nice. The patch applies cleanly and
On Fri, Nov 29, 2024 at 3:24 AM Jim Jones wrote:
>
>
> On 28.11.24 20:20, Kirill Gavrilov wrote:
> > Here is version 3 of this patch. I found another place where this
> > setting can be applied.
> > Also added some documentation and specified that this setting
> > truncates queries by size in
On 28.11.24 20:20, Kirill Gavrilov wrote:
> Here is version 3 of this patch. I found another place where this
> setting can be applied.
> Also added some documentation and specified that this setting
> truncates queries by size in bytes.
Thanks. It is now possible to change the parameter u
On Thu, Nov 28, 2024 at 5:23 PM Jim Jones wrote:
>
>
> On 25.11.24 17:52, Kirill Reshke wrote:
> > Hello! Please deliver the most recent patch version and fix the issues
> > Jim identified [0] as the current commitfest draws to a close.
> > Do not forget to include both parts of this patch (This
On 25.11.24 17:52, Kirill Reshke wrote:
> Hello! Please deliver the most recent patch version and fix the issues
> Jim identified [0] as the current commitfest draws to a close.
> Do not forget to include both parts of this patch (This was actually
> developed off-list, and we are now using this
On Tue, 1 Oct 2024 at 20:46, Kirill Gavrilov wrote:
>
> On Tue, Oct 1, 2024 at 2:46 PM Jim Jones wrote:
>>
>>
>> On 27.09.24 12:36, Andrey M. Borodin wrote:
>> > Consider max_log_size = 10Mb. The perspective might look very different.
>> > It’s not about WHERE anymore. It's a guard against heavy
On 01.10.24 17:46, Kirill Gavrilov wrote:
> My apologies, attached patch should work on master branch.
Nice.
I tested the feature and it does what it is intended to.
postgres=# SHOW max_log_size;
max_log_size
--
10
(1 row)
postgres=# INSERT INTO t VALUES (1,2,3,4,5,6,7,8,9,0);
On Fri, Sep 27, 2024 at 6:37 AM Andrey M. Borodin
wrote:
> Consider max_log_size = 10Mb. The perspective might look very different.
> It’s not about WHERE anymore. It's a guard against heavy abuse.
>
Can you elaborate on this? Do you mean someone purposefully writing large
entries to your log fi
On Tue, Oct 1, 2024 at 2:46 PM Jim Jones wrote:
>
> On 27.09.24 12:36, Andrey M. Borodin wrote:
> > Consider max_log_size = 10Mb. The perspective might look very different.
> > It’s not about WHERE anymore. It's a guard against heavy abuse.
> >
> > The feature looks very important for me.
> I ha
On 27.09.24 12:36, Andrey M. Borodin wrote:
> Consider max_log_size = 10Mb. The perspective might look very different.
> It’s not about WHERE anymore. It's a guard against heavy abuse.
>
> The feature looks very important for me.
I have the same opinion. As a fail safe it sounds very useful to m
> On 27 Sep 2024, at 03:30, Euler Taveira wrote:
>
> Let's say you arbitrarily provide max_log_size = 100
Consider max_log_size = 10Mb. The perspective might look very different. It’s
not about WHERE anymore. It's a guard against heavy abuse.
The feature looks very important for me.
Best
On Thu, Sep 26, 2024, at 3:30 PM, diPhantxm wrote:
> I would like to suggest a patch to truncate some long queries. I believe
> sometimes there is no need to log a query containing some gigabytes of blob,
> for example. In patch a new parameter, named max_log_size, is introduced. It
> defines th
19 matches
Mail list logo
