| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 8.0 -> 8.1 dump duplicate key problem? |
| Date: | 2005-11-14 19:01:15 |
| Message-ID: | 23892.1131994875@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On 11/14/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Do the "duplicate" rows appear to be independent insertions, or
>> successive states of the same logical row?
> 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.062
> 584527961 | 0 | 2005-09-15 11:17:17.187
> (2 rows)
I think you need to try this with enable_indexscan = 0; it should be
showing us 4 rows according to your prior result, and it's only showing
2, which suggests that the indexscan is short-circuiting because it
"knows" there can only be 1 result row. Also, since you're probing for
more than one primary key value, please include the pkey columns in the
query so we can tell what's what...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tino Wildenhain | 2005-11-14 19:16:04 | Re: functions marked STABLE not allowed to do INSERT |
| Previous Message | Merlin Moncure | 2005-11-14 18:39:22 | Re: 8.0 -> 8.1 dump duplicate key problem? |