installsite needs more memory than php cli has by default

i'm not too keen on this. drupal core devs are working on reducing mem requirement of the installer. try with latest head for some recent improvement.

I'm not keen on adjusting php memory either, but if it becomes necessary at some point, I'd recommend controlling memory limits via a global option that could be used with #671612: drush should support command-specific options. That would be better than hard-coding a constant that might hurt in some situations.

#671612: drush should support command-specific options has been committed, so with drush head you may now say (in any drushrc.php file):

$options['command-specific']['installsite'] = array('max-mem' => '64M');

I think your patch is okay, but I'll leave it to moshe to decide.

wild thought. should we add support for global and command specific php config like

$options['command-specific']['php-specific'] = array('memory_limit' => '64M');

that would free commands from having to deal with this.

er, edited code above for memory_limit

Well, I'm still not clear on why the OP doesn't just adjust the memory limit settings in his php-cli php.ini file. If that's not possible, the next best thing IMO would be to just plop down a call to ini_set('memory_limit', '64M'); in your drushrc.php file.

If you really needed to have the memory limit be set on a command-specific behavior, then you could define a global option that set it.

Either:

$options['memory-limit'] = '64M'; (separate code for each option)

Or:

$options['php-ini-memory-limit'] = '64M'; (one loop that gets the php-ini key from the option name)

Or like you suggested:

$options['php-ini'] = array( ... );

If you go as far as that, though, it would be tempting to just define drush contexts, allow contexts to have name hooks, and put your php-ini calls in your context hooks.

My inclination would be to pass on this patch, though, unless there's some strong reason why the memory setting needs to be command-specific.

ok, lets pass on this and see how many support requests we get.

yet another workaround is to start drush with something like php -d memory_limit=64M /path/to/drush.php. you can put that in your bash alias.

I have the same problem executing an pm-update

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 30720 bytes) in
/var/www/website/public/sites/all/modules/calendar/calendar_multiday/theme/theme.inc on line 275

The file mentioned changes every time I execute pm-update.

Is this related?

(Drupal 6.20, Drush 3.3, Debian Stable)