Re: pg primary key bug?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg primary key bug?
Дата
Msg-id 9340.1108664352@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg primary key bug?  (pginfo <pginfo@t1.unisoftbg.com>)
Список pgsql-sql
pginfo <pginfo@t1.unisoftbg.com> writes:
> Tom Lane wrote:
>> Could we see the system columns on these rows?

> 01=# select oid,xmin,cmin,xmax,cmax,ctid,* from a_constants_str where 
> constname='DOCPLAID';
>   oid  |  xmin   |  cmin   |  xmax   | cmax |  ctid  | constname | fid | 
> constvalue
> -------+---------+---------+---------+------+--------+-----------+-----+------------
>  17916 | 2232893 | 2235861 | 2235861 |   42 | (4,71) | DOCPLAID  |   0 | 
> SOF_19738
>  17916 | 2232893 | 2235861 | 2235861 |   41 | (7,62) | DOCPLAID  |   0 | 
> SOF_19738
> (2 rows)

Given the identical OID and xmin values, it seems certain that these are
the "same" row, ie there was only one insertion event.  My bet is that
the one at (7,62) is the original, and that the one at (4,71) is a copy
that was made by VACUUM FULL trying to move the row to compact the
table.  So the question is how did both copies get to be marked
simultaneously valid?  That should be impossible, unless a disk write
got dropped.  Have you had any system crashes during VACUUM FULL
operations recently?
        regards, tom lane


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

Предыдущее
От: Richard Huxton
Дата:
Сообщение: Re: LOOP?
Следующее
От: pginfo
Дата:
Сообщение: Re: pg primary key bug?