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: | Raw Message | Whole Thread | 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? |