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
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,
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
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
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-# '
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo