Closed Bug 557686 Opened 10 years ago Closed 10 years ago

PostgreSQL crashes when deleting a custom field of type Date/Time

Categories

(Bugzilla :: Administration, task)

task
Not set

Tracking

()

RESOLVED FIXED
Bugzilla 3.4

People

(Reporter: LpSolit, Assigned: LpSolit)

References

Details

(Keywords: selenium)

Attachments

(1 file)

DBD::Pg::db selectrow_array failed: ERREUR:  syntaxe en entrée invalide pour le type timestamp : «  » [for Statement "SELECT COUNT(*) FROM bugs WHERE cf_field5 IS NOT NULL AND cf_field5 != '' AND cf_field5 != '00-00-00 00:00:00'"] at Bugzilla/Field.pm line 738
	Bugzilla::Field::remove_from_db('Bugzilla::Field=HASH(0xad97978)') called at /var/www/html/bugzilla_qa36/editfields.cgi line 159
 at Bugzilla/Field.pm line 738
	Bugzilla::Field::remove_from_db('Bugzilla::Field=HASH(0xad97978)') called at /var/www/html/bugzilla_qa36/editfields.cgi line 159


Excluding the empty string as in bug 557495 doesn't help as it now throws:

DBD::Pg::db selectrow_array failed: ERREUR:  valeur du champ date/time en dehors des limites : « 00-00-00 00:00:00 »
HINT:  Peut-être avez-vous besoin d'un paramétrage « datestyle » différent. [for Statement "SELECT COUNT(*) FROM bugs WHERE cf_field5 IS NOT NULL AND cf_field5 != '00-00-00 00:00:00'"] at Bugzilla/Field.pm line 738
	Bugzilla::Field::remove_from_db('Bugzilla::Field=HASH(0x95dd948)') called at /var/www/html/bugzilla_qa36/editfields.cgi line 159
 at Bugzilla/Field.pm line 738
	Bugzilla::Field::remove_from_db('Bugzilla::Field=HASH(0x95dd948)') called at /var/www/html/bugzilla_qa36/editfields.cgi line 159

Here, it complains that '00-00-00 00:00:00' is not a valid date. Assuming this date can never be introduced, neither in MySQL nor in PostgreSQL, maybe should we simply skip it.
Flags: blocking3.6+
Flags: blocking3.4.7+
Attached patch patch, v1Splinter Review
'00-00-00 00:00:00' is not a valid date.
Assignee: administration → LpSolit
Status: NEW → ASSIGNED
Attachment #437464 - Flags: review?(mkanat)
Depends on: 349369
  That date can be introduced in MySQL by manual DB editors and other things. In fact, it probably could even be put into the database by a user in the interface.

  I don't think this should block 3.4.7 or 3.6--this only affects PostgreSQL 8.3, and there's probably even an option to disable the strictness.
(In reply to comment #2)
>   I don't think this should block 3.4.7 or 3.6--this only affects PostgreSQL
> 8.3, and there's probably even an option to disable the strictness.

I don't see how "this only affects Pg 8.3" doesn't make it a blocker. It's a crash, and you cannot delete the custom field at all. Also, the 3.4 branch will soon be locked to security fixes only.

I don't care that one can manually add '00-00-00 00:00:00' into the DB. This is not a valid date, and if someone managed to insert this date anyway, I'm fine with removing this field.
(In reply to comment #3)
> I don't care that one can manually add '00-00-00 00:00:00' into the DB. This is
> not a valid date, and if someone managed to insert this date anyway, I'm fine
> with removing this field.

Err... I should have said the opposite. If someone inserted this date, then the field will stay, which is not a big problem.
Comment on attachment 437464 [details] [diff] [review]
patch, v1

  Okay, that works for me. :-) I see you're the reviewer of the original patch, anyhow, so I'm OK with your decision on this.
Attachment #437464 - Flags: review?(mkanat) → review+
  It's sort of possible that a MySQL install before version 5.0 would contain these dates, by the way, since I think that's where those incorrect defaults of 0000-00-00 come from in MySQL DBs (from MySQL 4.1).
OK, we are safe. When entering a date in a Date/Time custom field, the checker _check_datetime_field() in Bug.pm makes sure that the date is valid by calling str2time(), which returns undef (false) if it's not. So you cannot insert 0000-00-00 at all.
Flags: approval3.6+
Flags: approval3.4+
Flags: approval+
Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/Field.pm
Committed revision 7116.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.6/
modified Bugzilla/Field.pm
Committed revision 7074.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/3.4/
modified Bugzilla/Field.pm
Committed revision 6758.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: testcase+
Keywords: selenium
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.