Re: the include-timestamp data returned by pg_logical_slot_peek_changes() is always 2000-01-01 in 9.5.1

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: 李海龙 <hailong(dot)li(at)qunar(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: the include-timestamp data returned by pg_logical_slot_peek_changes() is always 2000-01-01 in 9.5.1
Date: 2016-03-09 12:26:01
Message-ID: CAMsr+YGXuAS22tWJwBmsMCeadOM9+iegjc2g+aZqLqpPye4xqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9 March 2016 at 18:13, 李海龙 <hailong(dot)li(at)qunar(dot)com> wrote:

>
>
> HI, pgsql-hackers
>
> The include-timestamp data returned by pg_logical_slot_peek_changes() is
> always 2000-01-01 in 9.5.1, is it not normal?
>

Did you enable track_commit_timestamps in the server?

If not, and it's returning 2000-01-01 I think that's a bug - it should
return null if timestamps aren't recorded. (We can't really differentiate
between the real timestamp 2000-01-01 00:00:00 and the case where we didn't
record a timestamp, but I don't think we care about tx's generated on the
second of the millennium...)

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-03-09 12:27:10 Re: WIP: Access method extendability
Previous Message Alvaro Herrera 2016-03-09 12:22:45 Re: multivariate statistics v11