Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-17 Thread Merlin Moncure
On 11/16/05, Rod Taylor [EMAIL PROTECTED] wrote: On Mon, 2005-11-14 at 14:51 -0500, Tom Lane wrote: Merlin Moncure [EMAIL PROTECTED] writes: esp=# select prl_combined_key, prl_seq_no, xmin, xmax, lastmod from parts_order_line_file where prl_combined_key = ' 00136860' and prl_seq_no in

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-15 Thread Merlin Moncure
Rod Taylor [EMAIL PROTECTED] writes: Is there any chance it is related to the 8.0 problem I reported on Wednesday? Too soon to tell ... though one would like to think we don't have more than one bug in that area ;-). If either of you can come up with even a low-probability test case,

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Merlin Moncure
That's pretty bizarre. What's the datatype of the key column(s)? Can you reduce it to a smaller test case, or perhaps send me the full dump off-list? (270m is a bit much for email, but web or ftp would work ... also, presumably only the pkey column is needed to generate the error ...) I

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Merlin Moncure
On 11/14/05, Tom Lane [EMAIL PROTECTED] wrote: Merlin Moncure [EMAIL PROTECTED] 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

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Tom Lane
Merlin Moncure [EMAIL PROTECTED] writes: On 11/14/05, Tom Lane [EMAIL PROTECTED] 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-# '

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Merlin Moncure
On 11/14/05, Tom Lane [EMAIL PROTECTED] wrote: Merlin Moncure [EMAIL PROTECTED] writes: 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

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Merlin Moncure
On 11/14/05, Tom Lane [EMAIL PROTECTED] wrote: 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 one thing I forgot to mentionthere is a sequence on the table. Sequence is global for all tables

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Tom Lane
Merlin Moncure [EMAIL PROTECTED] writes: esp=# select prl_combined_key, prl_seq_no, xmin, xmax, lastmod from parts_order_line_file where prl_combined_key = ' 00136860' and prl_seq_no in (20, 23); prl_combined_key | prl_seq_no | xmin| xmax | lastmod

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Rod Taylor
On Mon, 2005-11-14 at 14:51 -0500, Tom Lane wrote: Merlin Moncure [EMAIL PROTECTED] writes: esp=# select prl_combined_key, prl_seq_no, xmin, xmax, lastmod from parts_order_line_file where prl_combined_key = ' 00136860' and prl_seq_no in (20, 23); prl_combined_key | prl_seq_no | xmin

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Tom Lane
Rod Taylor [EMAIL PROTECTED] writes: Is there any chance it is related to the 8.0 problem I reported on Wednesday? Too soon to tell ... though one would like to think we don't have more than one bug in that area ;-). If either of you can come up with even a low-probability test case, it'd be a

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-14 Thread Merlin Moncure
On 11/14/05, Tom Lane [EMAIL PROTECTED] wrote: The pairing seems very odd though: judging from the proximity of xmin and lastmod, the first and third rows were inserted at almost the same time, and they do *not* have equal keys; the rows they should have conflicted with were inserted some time

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-11 Thread Merlin Moncure
Merlin Moncure [EMAIL PROTECTED] writes: When the dump gets to the point where the indexes/keys are built, the primary key fails to build due to duplicate key constraint failure. However, after dump is complete, I can create the p-key without any modification to the table and everything

[HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-10 Thread Merlin Moncure
I have an interesting situation...am staging a mock upgrade from 8.0 to 8.1 on a bzip compressed backup image from one of our production servers. The dump image is big (270 mb compressed) and so is the file in question ~ 440k rows. Am piping the backup image to the server via psql -cd

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-10 Thread Tom Lane
Merlin Moncure [EMAIL PROTECTED] writes: When the dump gets to the point where the indexes/keys are built, the primary key fails to build due to duplicate key constraint failure. However, after dump is complete, I can create the p-key without any modification to the table and everything is

Re: [HACKERS] 8.0 - 8.1 dump duplicate key problem?

2005-11-10 Thread Dennis Bjorklund
On Thu, 10 Nov 2005, Tom Lane wrote: When the dump gets to the point where the indexes/keys are built, the primary key fails to build due to duplicate key constraint failure. That's pretty bizarre. What's the datatype of the key column(s)? There was one guy on IRC that had the same