[HACKERS] the include-timestamp data returned by pg_logical_slot_peek_changes() is always 2000-01-01 in 9.5.1

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？ The following is the test: [postgres@pgtest ~]$ cat /etc/issue CentOS release 6.4 (Final) Kernel \r on an \m [postgres@pgtest ~]$ uname -av Linux pgtest

Re: [HACKERS] 9.4 pg_control corruption

Understand! Before I wrote last email, I had initialized a new db with PostgreSQL 9.4beta2 and restored the pg_dumpall data of /export/pg94beta1_data/ Thanks Best Regards! at 2014-07-28 00:35 +08, Tom Lane wrote: > =?utf-8?B?5p2O5rW36b6Z?= writes: >> I have a PostgreSQL datadir named /expo

Re: [HACKERS] 9.4 pg_control corruption

Hi,dear steven && pgsql-hackers I've encountered the similar phenonmenon with 9.4 . 1. environment 1.1 OS version postgres@lhl-Latitude-E5420:~$ cat /etc/issue Ubuntu 13.10 \n \l postgres@lhl-Latitude-E5420:~$ uname -av Linux lhl-Latitude-E5420 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 1

Re: [HACKERS] I s this a bug of spgist index in a heavy write condition?

at 2013-01-12 02:21, Tom Lane wrote: =?gb2312?B?wO66o8H6?= writes: This time I will give you the contents of the table route_raw, the download link is https://www.box.com/s/yxa4yxo6rcb3dzeaefmz or http://dl.dropbox.com/u/203288/route_raw_spgist.sql.tar.gz . Th

Re: [HACKERS] I s this a bug of spgist index in a heavy write condition?

Hi,dear tom lane && pgsql-hackers In your last e-mail, you want me to think anbout the only spgist-indexed column and give you some more further information. This time I will give you the contents of the table route_raw, the download link is https://www.box.com/s/yxa4yxo6rcb3dzeaefmz or htt

Re: [HACKERS] I s this a bug of spgist index in a heavy write condition?

hi, The problem is not always appear on our system, we can't find a way to reproduce it. After rebuild the index with btree, the problem is disappear at 2012-12-14 00:16, Tom Lane wrote: > =?utf-8?B?5p2O5rW36b6Z?= writes: >> We have lots data to insert in that table which have the spgist ind

[HACKERS] I s this a bug of spgist index in a heavy write condition?

Hi,pgsql-hackers, I'm not sure whether it is a bug of using spgist index or not . OS Version: CentOS release 6.2 (Final) PostgreSQL Version: postgres=# select version(); version -- Pos