Jeff Davis wrote:
> On Mon, 2015-09-07 at 18:28 -0300, Alvaro Herrera wrote:
> > I think the extra ugliness is warranted, since it's not THAT much
> > additional ugliness, and not doing it could be considered a regression;
> > apparently strftime can be slower even than snprintf, so doing it twice
On Mon, 2015-09-07 at 18:28 -0300, Alvaro Herrera wrote:
> I noticed %t, but I don't think we care since the precision is so poor.
> Making m and n work in unison seems enough. I think it would be
> reasonably simple to handle %t in the same way, but I'm not sure we
> care.
OK.
> I think the ext
Jeff Davis wrote:
> > I wonder about this separate gettimeofday() call. We already have
> > formatted_log_time which is used for CSV logs and freeform log lines
> > (stderr/syslog); if we introduce a separate gettimeofday() call here,
> > and the user has %n in freeform log and CSV logging is acti
> I wonder about this separate gettimeofday() call. We already have
> formatted_log_time which is used for CSV logs and freeform log lines
> (stderr/syslog); if we introduce a separate gettimeofday() call here,
> and the user has %n in freeform log and CSV logging is active, the
> timings will div
On Mon, 2015-09-07 at 17:47 -0300, Alvaro Herrera wrote:
> Jeff Davis wrote:
> > On Sun, 2015-03-22 at 19:47 +0100, Andres Freund wrote:
> > > On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote:
> > > > from time to time I need to correlate PostgreSQL logs to other logs,
> > > > containing numeric ti
Jeff Davis wrote:
> On Sun, 2015-03-22 at 19:47 +0100, Andres Freund wrote:
> > On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote:
> > > from time to time I need to correlate PostgreSQL logs to other logs,
> > > containing numeric timestamps - a prime example of that is pgbench. With
> > > %t and %m
On Sun, 2015-03-22 at 19:47 +0100, Andres Freund wrote:
> On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote:
> > from time to time I need to correlate PostgreSQL logs to other logs,
> > containing numeric timestamps - a prime example of that is pgbench. With
> > %t and %m that's not quite trivial, b
> + case 'n':
> + {
> + struct timeval tv;
> + charstrfbuf[128];
> +
> + gettimeofday(&tv, NULL);
> +
On 08/23/2015 09:28 AM, Fabien COELHO wrote:
1) fix the docs (explicitly say that it's a Unix epoch)
I would add the word "numeric" in front of timestamp both in the doc and
in the postgresql.conf.sample, as it justifies the chosen %n.
I think we're already using 'unix epoch' in the docs
1) fix the docs (explicitly say that it's a Unix epoch)
I would add the word "numeric" in front of timestamp both in the doc and
in the postgresql.conf.sample, as it justifies the chosen %n.
I think we're already using 'unix epoch' in the docs without explicitly
stating that it's a numeric
On 08/22/2015 09:54 PM, Fabien COELHO wrote:
Hello Tomas,
Review of v2:
attached is a v2 of the patch, reworked based on the comments.
The patch applies cleanly to head, it compiles, I tested it and it
mostly work as expected, see below.
1) fix the docs (explicitly say that it's a Unix
Hello Tomas,
Review of v2:
attached is a v2 of the patch, reworked based on the comments.
The patch applies cleanly to head, it compiles, I tested it and it mostly
work as expected, see below.
1) fix the docs (explicitly say that it's a Unix epoch)
I would add the word "numeric" in fro
Hi all,
attached is a v2 of the patch, reworked based on the comments.
1) fix the docs (explicitly say that it's a Unix epoch)
2) handle 'padding' properly
3) get rid of timestamp_str - use appendString* methods directly
4) support just the "with milliseconds" using '%n' escape sequence
All
Hi,
On 08/22/2015 08:39 AM, Fabien COELHO wrote:
Hello Tomas,
from time to time I need to correlate PostgreSQL logs to other logs,
containing numeric timestamps - a prime example of that is pgbench. With
%t and %m that's not quite trivial, because of timezones etc.
I propose adding two new l
Hello Tomas,
from time to time I need to correlate PostgreSQL logs to other logs,
containing numeric timestamps - a prime example of that is pgbench. With
%t and %m that's not quite trivial, because of timezones etc.
I propose adding two new log_line_prefix escape sequences - %T and %M,
doing
On 23.3.2015 23:02, Jim Nasby wrote:
> On 3/22/15 2:59 PM, Tomas Vondra wrote:
>> On 22.3.2015 20:25, Fabien COELHO wrote:
>>
>>> I guess Tomas put 2 formats because there was 2 time formats
>>> to begin with, but truncating/rouding if someone really wants
>>> seconds is quite easy.
>>
>> Yes, that
On 3/22/15 2:59 PM, Tomas Vondra wrote:
On 22.3.2015 20:25, Fabien COELHO wrote:
>
>>>The proposed format is much simpler to manage in a script, and if you're
>>>interested in runtime, its formatting would be less expensive than %t
>>>and
>>>%m.
>>
>>Maybe, but do we really need two? How abou
The proposed format is much simpler to manage in a script, and if you're
interested in runtime, its formatting would be less expensive than %t and
%m.
Maybe, but do we really need two? How about just %M?
I guess Tomas put 2 formats because there was 2 time formats to begin
with, but trunca
On 22.3.2015 20:25, Fabien COELHO wrote:
>
>>> The proposed format is much simpler to manage in a script, and if you're
>>> interested in runtime, its formatting would be less expensive than %t
>>> and
>>> %m.
>>
>> Maybe, but do we really need two? How about just %M?
>
> I guess Tomas put 2 for
On 22.3.2015 19:45, Fabien COELHO wrote:
>
>>> I'm not sure that the "." in "%.03d" is useful. ISTM that it is used for
>>> floatting point formatting, but is not needed with integers.
>>
>> It is needed for integers, because you need to make sure 1 millisecond
>> is formatted as .001 and not .1.
[oops, stalled because of wrong From, resending just to the list]
On Sun, 22 Mar 2015, Tom Lane wrote:
The proposed format is much simpler to manage in a script, and if you're
interested in runtime, its formatting would be less expensive than %t and
%m.
Maybe, but do we really need two? How
On Sat, Mar 21, 2015 at 4:47 PM, Tomas Vondra
wrote:
> Hi,
>
> from time to time I need to correlate PostgreSQL logs to other logs,
> containing numeric timestamps - a prime example of that is pgbench. With
> %t and %m that's not quite trivial, because of timezones etc.
>
> I propose adding two n
Fabien COELHO writes:
>> On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote:
>>> from time to time I need to correlate PostgreSQL logs to other logs,
>>> containing numeric timestamps - a prime example of that is pgbench. With
>>> %t and %m that's not quite trivial, because of timezones etc.
>> I h
On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote:
from time to time I need to correlate PostgreSQL logs to other logs,
containing numeric timestamps - a prime example of that is pgbench. With
%t and %m that's not quite trivial, because of timezones etc.
I have a hard time seing this is suffic
On 2015-03-22 00:47:12 +0100, Tomas Vondra wrote:
> from time to time I need to correlate PostgreSQL logs to other logs,
> containing numeric timestamps - a prime example of that is pgbench. With
> %t and %m that's not quite trivial, because of timezones etc.
I have a hard time seing this is suffi
I'm not sure that the "." in "%.03d" is useful. ISTM that it is used for
floatting point formatting, but is not needed with integers.
It is needed for integers, because you need to make sure 1 millisecond
is formatted as .001 and not .1.
ISTM that the "03" does that on its own:
sh> printf
On 22.3.2015 08:14, David Rowley wrote:
> Hi Tomas,
>
> I just had a quick glance at this.
> Is there a reason you didn't include code to support the space padding
> for the new log_line_prefixes?
> The others support % in the prefix, to allow left or
> right alignment of the item.
Didn't realiz
On 22.3.2015 16:58, Fabien COELHO wrote:
>
> About the feature: I find it is a good thing. It may help scripting over
> the logs, for instance to compute delays between events, whereas the
> full date-time-tz syntax is maybe nice but heavier to work with afterwards.
>
> In addition to the comment
About the feature: I find it is a good thing. It may help scripting over
the logs, for instance to compute delays between events, whereas the full
date-time-tz syntax is maybe nice but heavier to work with afterwards.
In addition to the comments already made (typo in doc, padding...):
+s
On 22 March 2015 at 12:47, Tomas Vondra
wrote:
>
> I propose adding two new log_line_prefix escape sequences - %T and %M,
> doing the same thing as %t and %m, but formatting the value as a number.
>
>
Hi Tomas,
I just had a quick glance at this.
Is there a reason you didn't include code to suppo
Bruce Momjian wrote:
> On Sun, Mar 22, 2015 at 02:41:44AM +0100, Tomas Vondra wrote:
> > > Uh, I think you mean "number" here:
> > >
> > > Time stamp without milliseconds (as a numer)
> > > -
> >
> > Oh, right, that's a stupid typ
On Sun, Mar 22, 2015 at 02:41:44AM +0100, Tomas Vondra wrote:
> > Uh, I think you mean "number" here:
> >
> > Time stamp without milliseconds (as a numer)
> > -
>
> Oh, right, that's a stupid typo.
>
> >
> > Also, what "number"
On 22.3.2015 02:35, Bruce Momjian wrote:
> On Sun, Mar 22, 2015 at 12:47:12AM +0100, Tomas Vondra wrote:
>> Hi,
>>
>> from time to time I need to correlate PostgreSQL logs to other logs,
>> containing numeric timestamps - a prime example of that is pgbench. With
>> %t and %m that's not quite trivia
On Sun, Mar 22, 2015 at 12:47:12AM +0100, Tomas Vondra wrote:
> Hi,
>
> from time to time I need to correlate PostgreSQL logs to other logs,
> containing numeric timestamps - a prime example of that is pgbench. With
> %t and %m that's not quite trivial, because of timezones etc.
>
> I propose add
34 matches
Mail list logo
