Re: BUG #14940: Duplicated records inspite of primary key and uniqueconstraint
От | Сергей А. Фролов |
---|---|
Тема | Re: BUG #14940: Duplicated records inspite of primary key and uniqueconstraint |
Дата | |
Msg-id | d192b15c-d19c-61e3-9678-938500ed253c@smetarik.ru обсуждение исходный текст |
Ответ на | Re: BUG #14940: Duplicated records inspite of primary key and uniqueconstraint (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-bugs |
1. Yes, I have used pg_dump/pg_restore. I am sure that the ~10 problematic records were added on PG 9.6.5. and ~40 were added on PG 9.6.6., But I do not know when they were duplicated. 2. I have downloaded MS Win version from https://www.enterprisedb.com/downloads/postgres-postgresql-downloads#windows 01.12.2017 20:07, Tomas Vondra пишет: > Hi, > > On 12/01/2017 04:19 PM, Сергей А. Фролов wrote: >> The database was created at october 2016 on PG 9.5.3 then >> backuped/restored into PG 9.6.5 and then backuped/restored into PG 9.6.6. >> >> I am sure that the ~10 problematic records were added on PG 9.6.5. and >> ~40 were added on PG 9.6.6. >> > By backup/restore you mean pg_dump? If that's the case, it's pretty sure > the duplicates happened on 9.6.6 (otherwise the restore would fail). > > But that contradicts the 9.6.5 -> 9.6.6 upgrade, if your claim that 10 > duplicates originate on 9.6.5 is correct. > > BTW are you running vanilla PostgreSQL, or some of the EDB versions? > >> The file systems is NTFS. >> >> Windows 10 runs as virtual machine under Hyper-V. Windows logs contains >> nothing suspicious on both. >> > No idea. My experience with modern Windows systems is minimal, but I > suppose it certainly shouldn't corrupt data in normal operation. > >> I have wrote the script to generate select to check for duplicates all >> tables in all schemas - all other tables are OK. >> >> The only problem I observed - the PG dbugger hanged once and we had to >> kill related postgres process via taskmanager (killing session had no >> effect) , but I am shure that the killed session did not touch the >> problem table at all. >> > Not sure which debugger you mean, but again - killing a process should > not result in data corruption. It may cause the database to crash and > perform recovery, but that's about it. > > regards >
В списке pgsql-bugs по дате отправления: