Hello, everybody.
I solved the problem. The index has been corrupted after replication despite it
was appeared as not corrupted.
It was solved by recreating the index.
Thank you for the help.
--
Пожалуйста!
Используйте кнопку "ответить всем".
Не удаляйте историю переписки.
Спасибо. С уважением,
Sure, here it is.
pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
—xlog-method=stream —checkpoint=fast
/usr/pgsql-9.5/bin/initdb -D /data/upgrade/95/ —encoding=utf8
—locale=ru_RU.utf8 —lc-collate=ru_RU.utf8 —lc-ctype=ru_RU.utf8
—lc-messages=en_US.utf8
Then updating:
Yes, you are right. It's just a typo. -- Пожалуйста!Используйте кнопку "ответить всем".Не удаляйте историю переписки.Спасибо. С уважением, Timokhin 'maf' Maxim 30.06.2017, 02:38, "Adrian Klaver" :On 06/29/2017 02:28 AM, Timokhin Maxim wrote: Hello. We are in process
BTW, we are moving using:
pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
—xlog-method=stream —checkpoint=fast
After that we are upping version to 9.6.3.
I've looked through the documentation
https://postgrespro.ru/docs/postgrespro/9.6/app-pgbasebackup and didn't find
Hello! Yes, it looks like a bug or an index corruption. Now, I'm going to drop an index, find and fix duplicates, and create index again.But I would do it on 9.6.3 because there is a great feature ''max_parallel_workers_per_gather" there.Well, see what will happen. -- Пожалуйста!Используйте кнопку
Dear Michael,
I know what you mean. We also mail the issue to EDB.
Post here is just to reply Timokhin's case and see could anyone give a
solution.
EDB's strength is just a orafce moudule enhancement to me,
and I don't think they could adapt a lot of kernel module codes.
Regards,
On Mon, Jul 3, 2017 at 10:08 AM, Steven Chang wrote:
> Hello :
Please avoid top-posting.
>PG VERSION : PPAS 9.3 , enterprisedb
>os version : 2.6.32-358.el6.x86_64
This is EnterpriseDB's fork of Postgres. Until it can be proved that a
corruption has
Hello :
PG VERSION : PPAS 9.3 , enterprisedb
os version : 2.6.32-358.el6.x86_64
pg_basebackup job was not performed by me. But I think it was executed
regularly.
Any switch or parameter would cause this issue ???
Why I don't think not a index curruption issue ?
1. I
On Sat, Jul 1, 2017 at 10:05 AM, Adrian Klaver
wrote:
> On 06/30/2017 09:42 PM, Steven Chang wrote:
>
>> Uh...we also met duplicate rows with primary key column through
>> restoring database by pg_basebackup.
>> H.
>> I don't think its an
On 06/30/2017 09:42 PM, Steven Chang wrote:
Uh...we also met duplicate rows with primary key column through
restoring database by pg_basebackup.
H.
I don't think its an issue with primary key index corruption.
That is interesting, more information would be
Uh...we also met duplicate rows with primary key column through restoring
database by pg_basebackup.
H.
I don't think its an issue with primary key index corruption.
2017-07-01 7:30 GMT+08:00 Adrian Klaver :
> On 06/30/2017 07:33 AM,
On 06/30/2017 07:33 AM, Timokhin Maxim wrote:
Sure, here it is.
pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
—xlog-method=stream —checkpoint=fast
/usr/pgsql-9.5/bin/initdb -D /data/upgrade/95/ —encoding=utf8
—locale=ru_RU.utf8 —lc-collate=ru_RU.utf8 —lc-ctype=ru_RU.utf8
On Fri, Jun 30, 2017 at 9:07 AM, Adrian Klaver
wrote:
> On 06/30/2017 04:58 AM, Timokhin Maxim wrote:
>
>> BTW, we are moving using:
>>
>> pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
>> —xlog-method=stream —checkpoint=fast
>>
>
> Going from 9.4 to
On 06/30/2017 04:58 AM, Timokhin Maxim wrote:
BTW, we are moving using:
pg_basebackup -h servername -R -P -D /data/upgrade/94 -U pgsql -v
—xlog-method=stream —checkpoint=fast
Going from 9.4 to 9.6 is a major version upgrade and you cannot use
pg_basebackup for that. Besides I can't see how
Interesting!! We also met the same situation on PK running on PPAS 9.0 last
night.
When surfing Internet, got returned this URL :
https://www.postgresql.org/message-id/20140811083748.2536.10437%40wrigleys.
postgresql.org
On 06/29/2017 02:28 AM, Timokhin Maxim wrote:
Hello.
We are in process moving to new db from 9.4.8 -> 9.6.3.1. When we did it
our application started to throw exception "duplicate key value violates
unique constraint" during doing INSERT:
How did move from 9.4.8 --> 9.6.3.1?
Also where are
Hello.We are in process moving to new db from 9.4.8 -> 9.6.3.1. When we did it our application started to throw exception "duplicate key value violates unique constraint" during doing INSERT: INSERT INTO items (ctime, mtime, pubdate, url, title, description, body, status, fulltext_status, orig_id,
On Thu, Jun 29, 2017 at 5:28 AM, Timokhin Maxim wrote:
> Hello.
> We are in process moving to new db from 9.4.8 -> 9.6.3.1. When we did it
> our application started to throw exception "duplicate key value violates
> unique constraint" during doing INSERT:
>
> INSERT INTO items
18 matches
Mail list logo