Wikimedia Bugzilla is closed!

petrb@deployment-dbdump:/tmp$ tail nohup.out
...user_last_timestamp is already nullable.
...user_email key already set on user table.
...up_property in table user_properties already modified by patch patch-up_property.sql.
...uploadstash table already exists.
...user_former_groups table already exists.
...config table already exists.
...type_action key already set on logging table.
...batch conversion of user_options: nothing to migrate. done.
...user table does not contain user_options field.
Adding rev_sha1 field to table revision...

this is there in a log for several hours

You could run populateRevisionSha1.php.

sounds like this should block deployment or at least tarball.

(In reply to comment #3)
> sounds like this should block deployment or at least tarball.

Definitely doesn't block deployment, we don't use update.php.

Does that mean that the Adding rev_sha1 field to table revision... does not output anything? I guess it should either:
- output something every X sha1 are computed
- skip that step and raise a nice warning explicitly asking user to run populateRevisionSha1.php

(In reply to comment #5)
> Does that mean that the Adding rev_sha1 field to table revision... does not
> output anything? I guess it should either:
> - output something every X sha1 are computed
> - skip that step and raise a nice warning explicitly asking user to run
> populateRevisionSha1.php

Indeed, with it potentially being really slow, there's little point actually just automagically running it IMHO

Oh wait. It's not an issue populating the field, it's the issue of it taking a long time (Asher suggests about 30 hours for enwiki size) to add the field to the revision table

no actually it didn't work at all, after 10 hours of run it didn't even update structure of db, no update of table was done either

How big is the table?

I will check the details soon, the db itself (all tables) have around 38gb, it
was a complete dump of simple db

this query was run after the start of update.php

desc revision;
+----------------+---------------------+------+-----+----------------+----------------+
| Field          | Type                | Null | Key | Default        | Extra   
      |
+----------------+---------------------+------+-----+----------------+----------------+
| rev_id         | int(10) unsigned    | NO   | PRI | NULL           |
auto_increment |
| rev_page       | int(10) unsigned    | NO   | MUL | NULL           |         
      |
| rev_text_id    | int(10) unsigned    | NO   |     | NULL           |         
      |
| rev_comment    | tinyblob            | NO   |     | NULL           |         
      |
| rev_user       | int(10) unsigned    | NO   | MUL | 0              |         
      |
| rev_user_text  | varbinary(255)      | NO   | MUL |                |         
      |
| rev_timestamp  | binary(14)          | NO   | MUL |                |         
      |
| rev_minor_edit | tinyint(3) unsigned | NO   |     | 0              |         
      |
| rev_deleted    | tinyint(3) unsigned | NO   |     | 0              |         
      |
| rev_len        | int(10) unsigned    | YES  |     | NULL           |         
      |
| rev_parent_id  | int(10) unsigned    | YES  |     | NULL           |         
      |
+----------------+---------------------+------+-----+----------------+----------------+

it's clear that it didn't even update structure so that I doubt it would actually work. But it happened to me only on larger db's

I've no idea how table alters work if you cancel them, rather than letting them execute through

I didn't cancel anything that is how table was looking during the update, I mean that it was running for hours and meanwhile there was no activity in the sql server

(In reply to comment #13)
> I didn't cancel anything that is how table was looking during the update, I
> mean that it was running for hours and meanwhile there was no activity in the
> sql server

What did SHOW PROCESSLIST output during that time of seemingly no activity?

removing from tarball blocker:

<hashar> I guess we want to try to reproduce 33558 with Peter using the labs
<hashar> then we will be able to investigate the issue
<hashar> not much we can do right now