api response for database error includes traceback
Bug #1314099 reported by
Michael Nelson
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ratings and Reviews server |
Triaged
|
High
|
Fabián Ezequiel Gallina |
Bug Description
This should be returning an oops ID in the response content.
We do have oopses for other errors, so need to check what's special here that causes the traceback to be included:
To post a comment you must log in.
After a search on the matter I think this becomes really two issues:
1. is the database error itself.
2. the oopses machinery failing to handle this.
For #1 I think it's related to upgrading from Postgres 8.x to 9.1.
I was confirmed we are using 9.1.9-0ubuntu12.04 and from wiki and logs I understand RnR started its life in Natty which had 8.4.
Now on Postgres release notes (http:// www.postgresql. org/docs/ 9.1/static/ release- 9-1-2.html) there's this excerpt:
Make contrib/citext's upgrade script fix collations of citext
columns and indexes (Tom Lane)
Existing citext columns and indexes aren't correctly marked as
being of a collatable data type during pg_upgrade from a pre-9.1
server, or when a pre-9.1 dump containing the citext type is
loaded into a 9.1 server. That leads to operations on these
columns failing with errors such as "could not determine which
collation to use for string comparison". This change allows them
to be fixed by the same script that upgrades the citext module
into a proper 9.1 extension during CREATE EXTENSION citext FROM
unpackaged.
If you have a previously-upgraded database that is suffering from extension/ citext- -unpackaged- -1.0.sql. (Run
this problem, and you already ran the CREATE EXTENSION command,
you can manually run (as superuser) the UPDATE commands found at
the end of SHAREDIR/
pg_config --sharedir if you're uncertain where SHAREDIR is.) There
is no harm in doing this again if unsure.
So I think that running this may fix the database error itself.
Now WRT to the oops, I wasn't able to replicate it, probably code
changed since then and this is not happening anymore, I'll try harder
but I think it's important to ensure the COLLATE error won't happen
again.