Re: BUG #8382: Duplicate primary key

Поиск
Список
Период
Сортировка
От Curd Reinert
Тема Re: BUG #8382: Duplicate primary key
Дата
Msg-id OF17CBD320.052C6C0E-ONC1257BC7.002DA09F-C1257BC7.002E8920@ppi.de
обсуждение исходный текст
Ответ на Re: BUG #8382: Duplicate primary key  (Greg Stark <stark@mit.edu>)
Список pgsql-bugs
Hello Greg,

gsstark@gmail.com schrieb am 13.08.2013 19:50:35:
> The current bug-fix release for Postgres 9 is 9.0.13. There was an
> extremely high profile security vulnerability fixed in 9.0.13 so I
> would strongly recommend updating.
Yes, I noticed that one. However, those installations are not exposed to
the outside, they do have backups, the data inside the database is not
very critical and there are about 1.000 installations to update. I don't
think I can make our customer update all of them. Should be no problem for
the one that is causing the trouble, though.

> I see bugs that could cause this in both 9.0.7 and 9.0.11.
Okay. I thought I checked the list of fixed bugs, but didn't notice them
then. I can see them now you've pointed me to the relevant patch levels. I
will tell our cutomer to update that installation to 9.0.13.

> Unless you're calling CREATE INDEX CONCURRENTLY
> *often* on this system?
Never. As we use practically the same code for Postgres, DB2 and Oracle,
we are stuck to plain old SQL and don't do anything but selects, inserts,
updates and deletes. And I'm pretty sure our customer isn't touching the
database, either.

> Do you know anything about the history of how often the system was
> rebooted -- either the host or the virtual machine?
I can't say for sure, but it seems that the VM is rebooted at least every
night. I have no idea about the host.

> Also, have you run a memory checker on the system?
I'm two levels remote from the machine, but I will pass it on.

Thank you very much.

Curd

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: BUG #8382: Duplicate primary key
Следующее
От: "ascot.moss@gmail.com"
Дата:
Сообщение: Re: Recovery.conf PITR by recovery_target_time