Edgewall Software
Modify

Opened 16 years ago

Closed 16 years ago

Last modified 8 years ago

#3885 closed defect (wontfix)

Unable to browse source. Fails with "duplicate key violates unique constraint 'revision_pkey'

Reported by: dhaval.shah.m@… Owned by: Christian Boos
Priority: high Milestone:
Component: version control/changeset view Version: 0.10
Severity: blocker Keywords: perforce, changeset, postgresql
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Matthew Good)

I am using trac 0.10.

We are looking to integrate it with Perforce and Postgres. The perforce change list is very large.

Postgres v 8.1.4, Perforce v 2.5…

When I do "browse source", I get the following error :

Traceback (most recent call last):
  File "/home/trac/lib/python2.4/site-packages/trac/web/main.py", line 356, in dispatch_request
    dispatcher.dispatch(req)
  File "/home/trac/lib/python2.4/site-packages/trac/web/main.py", line 224, in dispatch
    resp = chosen_handler.process_request(req)
  File "/home/trac/lib/python2.4/site-packages/trac/versioncontrol/web_ui/browser.py", line 131, in process_request
    self._render_directory(req, repos, node, rev)
  File "/home/trac/lib/python2.4/site-packages/trac/versioncontrol/web_ui/browser.py", line 156, in _render_directory
    changes = get_changes(self.env, repos, [i['rev'] for i in info])
  File "/home/trac/lib/python2.4/site-packages/trac/versioncontrol/web_ui/util.py", line 37, in get_changes
    changeset = repos.get_changeset(rev)
  File "/home/trac/lib/python2.4/site-packages/trac/versioncontrol/cache.py", line 41, in get_changeset
    self.sync()
  File "/home/trac/lib/python2.4/site-packages/TracPerforce-0.4.2-py2.4.egg/p4trac/api.py", line 227, in sync
  File "/home/trac/lib/python2.4/site-packages/TracPerforce-0.4.2-py2.4.egg/p4trac/api.py", line 203, in updateCache
  File "/home/trac/lib/python2.4/site-packages/TracPerforce-0.4.2-py2.4.egg/p4trac/api.py", line 153, in storeChangesInDB
  File "/home/trac/lib/python2.4/site-packages/trac/db/util.py", line 47, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/home/trac/lib/python2.4/site-packages/trac/db/util.py", line 47, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/home/trac/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 3111, in execute
    raise OperationalError, msg
OperationalError: ERROR:  duplicate key violates unique constraint "revision_pkey"

At this stage, the revision table in the postgres has this many rows …

trac=> select count(*) from revision;
 count
-------
 35560
(1 row)

The last row has the max time as follows :

trac=> select max(time) from revision;
    max
------------
 1065487402
(1 row)

trac=> select count(*) from (select distinct(rev) from revision) as dist_rev_count;
 count
-------
 35560
(1 row)

Note that the node_change table has more than 2 million+ rows.

The above data indicates that trac is trying to resync from a given time and then gives up when it runs into a "duplicate" key violation.

Here are the issues :

  1. Trac should not "give up" when it runs into a unique constraint violation while inserting rows into the revision table. It is also possible that this is a resync error.

An alternative is to *not* specify the revision(rev) as the primary index.

Also in postgres, there is a "copy to" command that takes in a text file and inserts the rows into the db. It is very fast. Tracd resync should implement that.

Attachments (0)

Change History (5)

comment:1 by anonymous, 16 years ago

It is also possible that multiple users may have selected browse source view leading to multiple insertions of the row with same rev id.

comment:2 by anonymous, 16 years ago

Further revision number should be integer rather than text in table revision and node_change!

comment:3 by Matthew Good, 16 years ago

Description: modified (diff)

fixing formatting of description

comment:4 by Christian Boos, 16 years ago

Resolution: wontfix
Status: newclosed

An alternative is to *not* specify the revision(rev) as the primary index.

We're going to do that anyway for the sake of MySQL support (see #3676).

Further revision number should be integer rather than text in table revision and node_change!

rev ids are not always numbers (e.g. Monotone, Darcs, …)

Anyway, I think you should report this error to TracHacks:PerforcePlugin, as the backend is responsible for creating the changesets that are later put into the cache. I can't really see why there could be duplicates for (rev,path,modif_type), so I think it's a bug in the backend. We recently had one of this kind in the Subversion backend (#3778).

comment:5 by Ryan J Ollos, 8 years ago

Keywords: postgresql added; postgres removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.