Edgewall Software
Modify

Opened 8 years ago

Closed 7 months ago

#3948 closed defect (wontfix)

Can't add a new report

Reported by: anonymous Owned by: mgood
Priority: normal Milestone:
Component: report system Version: 1.0.1
Severity: minor Keywords: postgresql upgrade documentation
Cc: johngluck@…, chris+trac@…
Release Notes:
API Changes:

Description (last modified by cboos)

I get this when I save a new report

Python Traceback

Traceback (most recent call last):
  File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 356, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 224, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/local/lib/python2.4/site-packages/trac/ticket/report.py", line 79, in process_request
    self._do_create(req, db)
  File "/usr/local/lib/python2.4/site-packages/trac/ticket/report.py", line 128, in _do_create
    "VALUES (%s,%s,%s)", (title, query, description))
  File "/usr/local/lib/python2.4/site-packages/trac/db/util.py", line 47, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/local/lib/python2.4/site-packages/trac/db/util.py", line 47, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/local/lib/python2.4/site-packages/pyPgSQL/PgSQL.py", line 3111, in execute
    raise OperationalError, msg
OperationalError: ERROR:  duplicate key violates unique constraint "report_pkey"

Attachments (0)

Change History (17)

comment:1 Changed 8 years ago by anonymous

I've already updated my system from 0.9 to 0.10. With version 0.9 this feature worked great.

comment:2 follow-up: Changed 8 years ago by anonymous

  • Resolution set to fixed
  • Status changed from new to closed

Solved adding one manually to the database. May be during the update process from .9 to .10 some counter didn't update properly

comment:3 follow-up: Changed 8 years ago by cboos

  • Description modified (diff)
  • Resolution fixed deleted
  • Status changed from closed to reopened

(wrong resolution type, fixed should be used only for issues requiring code changes)

Did you also switch from SQLite to PostgreSQL at the same time?

comment:4 in reply to: ↑ 3 Changed 8 years ago by mgood

  • Resolution set to worksforme
  • Status changed from reopened to closed

Replying to cboos:

(wrong resolution type, fixed should be used only for issues requiring code changes)

I assume you meant to change the resolution to worksforme.

comment:5 in reply to: ↑ 2 Changed 8 years ago by anonymous

Replying to anonymous:

Solved adding one manually to the database. May be during the update process from .9 to .10 some counter didn't update properly

PostgreSQL7 has this problem after initial instance creation. Something with serial id field, I believe.

For those who want to to that, exact sql queries (add report and then remove it):

INSERT INTO report (title,query,description)
  VALUES ('one more test report', 'select 3*3', 'ZZZ')

DELETE FROM report
  WHERE query = 'select 3*3' and description = 'ZZZ'

comment:6 Changed 8 years ago by mikef@…

  • Resolution worksforme deleted
  • Status changed from closed to reopened

The migration is _broken_ from 0.9 to 0.10 with Postgres. I had to manually set the sequence to the right value.

comment:7 Changed 8 years ago by cboos

  • Keywords postgresql upgrade added
  • Milestone set to 0.10.5
  • Priority changed from high to normal
  • Severity changed from normal to minor

I don't think this is ever going to be fixed, but it could be documented.

comment:8 Changed 7 years ago by anonymous

  • Cc chris+trac@… added

How can it be worked around?

comment:9 Changed 7 years ago by anonymous

Yes, how can this be worked around. Please leave instructions?

comment:10 Changed 7 years ago by anonymous

  • Cc johngluck@… added; chris+trac@… removed

Please tell us how to work around this problem

comment:11 Changed 7 years ago by anonymous

  • Cc chris+trac@… added

please don't remove me from the CC:

comment:12 Changed 7 years ago by tankcatninjafish@…

This is what I did to fix for postgresql 8.1 and trac 10.4 (which I upgraded from .9.something). Background info: Auto incrementing Primary keys in postgresql tables have a counter which you can manually view and modify. So the reports table has a counter 'report_id_seq'::regclass

\d report;
                            Table "public.report"
   Column    |  Type   |                      Modifiers
-------------+---------+-----------------------------------------------------
 id          | integer | not null default nextval('report_id_seq'::regclass)
 author      | text    |
 title       | text    |
 query       | text    |
 description | text    |

To see the current counter value, do:

select currval('report_id_seq'::regclass);
 currval
---------
       8
(1 row)

8 is definitely wrong because I have around 30 or so reports. So I'll reset it to something high like 40:

select setval('report_id_seq'::regclass,40);
 setval
--------
     40
(1 row)

And the next report should be added correctly with and ID of 41 (which is 40 + 1 because the counter gets incremented). Hopes this helps some unlucky soul.

comment:13 Changed 6 years ago by ischenko@…

I can confirm the problem on Trac 0.11rc1. It seems that either counter is not updated or Trac doesn't see refreshed value. After I used setval to update id I tried to create yet another report and it used previously used id. So basically I have to setval each time I need a report defined.

comment:14 Changed 5 years ago by cboos

  • Keywords documentation added
  • Milestone changed from 0.10.6 to 0.11.6

#8011 was closed as duplicate.

I repeat what I said there: don't use PgSQL…

We should probably state that only psycopg2 is supported.

comment:15 Changed 5 years ago by rblank

  • Milestone next-minor-0.12.x deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

We're not going to fix the older 0.9 → 0.10 → 0.11 upgrade scripts, for which comment:12 describes a fix. However, we are going to implement the next upgrade script for the ticket or report tables (the only ones with auto-increment columns) properly.

comment:16 follow-up: Changed 15 months ago by ben@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 0.10 to 1.0.1

I have this same issues with a new (not upgraded) 1.0.1 Trac install.

I'll use the workaround mentioned above for now, but figured I would reopen this ticket so this issue can be checked into as possibly resurfacing in the newer version.

Environment details:

  • Trac 1.0.1
  • Postgresql 9.2.4

Log Output

2013-06-27 17:52:03,124 Trac[main] ERROR: Internal Server Error: 
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/trac/web/main.py", line 497, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.7/site-packages/trac/web/main.py", line 214, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.7/site-packages/trac/ticket/report.py", line 160, in process_request
    self._do_create(req)
  File "/usr/lib/python2.7/site-packages/trac/ticket/report.py", line 221, in _do_create
    """, (title, query, description))
  File "/usr/lib/python2.7/site-packages/trac/db/util.py", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
IntegrityError: duplicate key value violates unique constraint "report_pkey"
DETAIL:  Key (id)=(11) already exists.
IntegrityError: duplicate key value violates unique constraint "report_pkey"
DETAIL:  Key (id)=(11) already exists.

comment:17 in reply to: ↑ 16 Changed 7 months ago by jomae

  • Resolution set to wontfix
  • Status changed from reopened to closed

Replying to ben@…:

I have this same issues with a new (not upgraded) 1.0.1 Trac install.

Please create a new ticket with how to reproduce on a new environment rather than reopen the old ticket. Thanks.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain mgood.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from mgood to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.