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
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
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
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
> 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
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
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,
> + case 'n':
> + {
> + struct timeval tv;
> + charstrfbuf[128];
> +
> + gettimeofday(, NULL);
> +
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/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
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
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
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
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
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
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
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 about just %M?
I
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's why I added
On 22 March 2015 at 12:47, Tomas Vondra tomas.von...@2ndquadrant.com
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
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...):
+
Fabien COELHO coe...@cri.ensmp.fr 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
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 formats because there
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 comments
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
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 %03d\n
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.
ISTM that the
On Sat, Mar 21, 2015 at 4:47 PM, Tomas Vondra tomas.von...@2ndquadrant.com
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.
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 new log_line_prefix escape sequences - %T and %M,
doing the same
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 trivial, because
On Sun, Mar 22, 2015 at 02:41:44AM +0100, Tomas Vondra wrote:
Uh, I think you mean number here:
entryTime stamp without milliseconds (as a numer)/entry
-
Oh, right, that's a stupid typo.
Also, what number do you
Bruce Momjian wrote:
On Sun, Mar 22, 2015 at 02:41:44AM +0100, Tomas Vondra wrote:
Uh, I think you mean number here:
entryTime stamp without milliseconds (as a numer)/entry
-
Oh, right, that's a stupid typo.
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 adding
32 matches
Mail list logo
