Обсуждение: Confusing with commit time usage in logical decoding

Поиск
Список
Период
Сортировка

Confusing with commit time usage in logical decoding

От
Weiping Qu
Дата:
If you received this message twice, sorry for annoying since I did not
subscribe successfully previously due to conflicting email domain.

Dear postgresql general mailing list,

I am currently using the logical decoding feature (version 9.6 I think
as far as I found in the source, wal_level: logical,
max_replication_slot: > 1, track_commit_timestamp: on, I am not sure
whether this will help or not).
Following the online documentation, everything works fine until I input

SELECT * FROM pg_logical_slot_peek_changes('regression_slot', NULL,
NULL, 'include-timestamp', 'on');


I always got 1999-12-31 16:00 as the commit time for arbitrary
transactions with DML statements.
After several tries, I realize that the txn->commit_time returned was
always 0.
Could you help me by indicating me what could be wrong in my case? Any
missing parameters set?

Thank you in advance,
Kind Regards,
Weiping


Re: Confusing with commit time usage in logical decoding

От
Andres Freund
Дата:
Hi,

On 2016-02-29 11:12:14 +0100, Weiping Qu wrote:
> If you received this message twice, sorry for annoying since I did not
> subscribe successfully previously due to conflicting email domain.
>
> Dear postgresql general mailing list,
>
> I am currently using the logical decoding feature (version 9.6 I think as
> far as I found in the source, wal_level: logical, max_replication_slot: > 1,
> track_commit_timestamp: on, I am not sure whether this will help or not).
> Following the online documentation, everything works fine until I input
>
> SELECT * FROM pg_logical_slot_peek_changes('regression_slot', NULL, NULL,
> 'include-timestamp', 'on');
>
>
> I always got 1999-12-31 16:00 as the commit time for arbitrary transactions
> with DML statements.
> After several tries, I realize that the txn->commit_time returned was always
> 0.
> Could you help me by indicating me what could be wrong in my case? Any
> missing parameters set?

That was a bug introduced recently (9.5).  The issue was discussed in
http://archives.postgresql.org/message-id/56D42918.1010108%40postgrespro.ru
, and a fix has now been pushed.

Thanks for the report!

Regards,

Andres