Re: 8.0 -> 8.1 dump duplicate key problem?

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: 8.0 -> 8.1 dump duplicate key problem?
Дата
Msg-id b42b73150511141039q1067543brc788ee5ae71cc710@mail.gmail.com
обсуждение исходный текст
Ответ на 8.0 -> 8.1 dump duplicate key problem?  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Ответы Re: 8.0 -> 8.1 dump duplicate key problem?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 11/14/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
> > I just confirmed that there are duplicate p-keys in the source table :(.
>
> Well, that's not very good either, but at least it narrows down the
> problem.
>
> Do the "duplicate" rows appear to be independent insertions, or
> successive states of the same logical row?  Looking at their xmin/xmax
> might help determine this, and if the table has OIDs then looking at the
> oid would be pretty conclusive.

no oid.
esp=# select xmin, xmax, lastmod from parts_order_line_file where
prl_combined_key =
esp-# ' 00136860' and prl_seq_no in (20, 23);  xmin    | xmax |         lastmod
-----------+------+-------------------------584527952 |    0 | 2005-09-15 11:17:17.062584527961 |    0 | 2005-09-15
11:17:17.187
(2 rows)

the nature of the file, unfortunately is that a record may be
rewritten several times over it's lifespan, due to ISAM style
resequencing on the table.   the file is taken directly from user
entry app so high speec race condition type behavior is unlikely, save
for a order duplication aspect I need to check into.

Being a ported COBOL app, tranasactions are one-record wonders, save
for places where parts have been rewritten in pl/pgsql (does not apply
here).

Merlin


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

Предыдущее
От: Robert Treat
Дата:
Сообщение: Re: functions marked STABLE not allowed to do INSERT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 8.0 -> 8.1 dump duplicate key problem?