This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
On Mon, 20 Jun 2022 at 11:01, Tom Lane wrote:
> Alvaro Herrera writes:
>
> If I were coding it, I would allow only exactly 1 digit (%.Nt) to simplify
> the parsing side of things and bound the required buffer size. Without
> having written it, it's not clear to me whether further restricting
Alvaro Herrera writes:
> Do we *have* to provide support for arbitrary numbers of digits, though?
> We could provide support for only %.3t and %.6t specifically, and not
> worry about other cases (error: width not supported).
If I were coding it, I would allow only exactly 1 digit (%.Nt) to
On 2022-Jun-14, David Fetter wrote:
> On Mon, Jun 13, 2022 at 04:22:42PM -0400, Tom Lane wrote:
> > A different line of thought is to extend %t to provide a precision
> > field a la sprintf, so that for example "%.3t" is equivalent to
> > "%m" and "%.6t" does what David wants, and we won't have
On Mon, Jun 13, 2022 at 04:22:42PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, May 8, 2022 at 4:45 PM David Fetter wrote:
> >> Please find attached a patch to change the sub-second granularity of
> >> log timestamps from milliseconds to microseconds.
>
> > Why is this a good idea?
Robert Haas writes:
> On Sun, May 8, 2022 at 4:45 PM David Fetter wrote:
>> Please find attached a patch to change the sub-second granularity of
>> log timestamps from milliseconds to microseconds.
> Why is this a good idea?
I can imagine that some people would have a use for microsecond
On Sun, May 8, 2022 at 4:45 PM David Fetter wrote:
> Please find attached a patch to change the sub-second granularity of
> log timestamps from milliseconds to microseconds.
Why is this a good idea?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, May 09, 2022 at 11:21:26AM +0100, Dagfinn Ilmari Mannsåker wrote:
> David Fetter writes:
>
> > diff --git src/backend/utils/error/elog.c src/backend/utils/error/elog.c
> > index 55ee5423af..4698e32ab7 100644
> > --- src/backend/utils/error/elog.c
> > +++ src/backend/utils/error/elog.c
>
David Fetter writes:
> diff --git src/backend/utils/error/elog.c src/backend/utils/error/elog.c
> index 55ee5423af..4698e32ab7 100644
> --- src/backend/utils/error/elog.c
> +++ src/backend/utils/error/elog.c
> @@ -2295,7 +2295,7 @@ char *
> get_formatted_log_time(void)
> {
> pg_time_t
On Sun, May 08, 2022 at 04:12:27PM -0500, Justin Pryzby wrote:
> On Sun, May 08, 2022 at 08:44:51PM +, David Fetter wrote:
> > CREATE TABLE postgres_log
> > (
> > - log_time timestamp(3) with time zone,
> > + log_time timestamp(6) with time zone,
>
> Please also update the corresponding
On Sun, May 08, 2022 at 08:44:51PM +, David Fetter wrote:
> CREATE TABLE postgres_log
> (
> - log_time timestamp(3) with time zone,
> + log_time timestamp(6) with time zone,
Please also update the corresponding thing in doc/src/sgml/file-fdw.sgml
It looks like the patch I suggested to
Folks,
Please find attached a patch to change the sub-second granularity of
log timestamps from milliseconds to microseconds.
I started out working on a longer patch that will give people
more choices than whole seconds and microseconds, but there were a lot
of odd corner cases, including what
12 matches
Mail list logo
