I’m storing some user info in session (like the name, using cookies), in Ruby on Rails 3.2
IMO it's on the user at that point. Don't muddle yourself with details like that when it's their own problem and something that would require (possibly depending on how you go about it) significant code changes that could drastically affect performance.
Depending on how you go about it anyways, normally you would hit the database everytime anyways and later with some clever side jobs to pull and commit and update cached records later (or other ways it really depends on the developer,) why not just use the ActiveRecord object you pull and show their name? There are cases where you wouldn't do that but such as a userless site that just stores their name in a cookie to preference the site but you can't really control that situation at all.
What I am saying is there are several ways you can go about it, one is to switch to ActiveRecord sessions and add an extra key ("username") that is only used to find and delete sessions when a user updates their record, this would kill all possible sessions but adds extra overhead in terms of the username and even extra overhead in terms of ActiveRecord (but then again this is more secure and you could even get clever and pull from Memcached and delay the commit and memcached update with delayed_job reducing impact on the user.)
The third way would be to just update the session when you pull their record from ActiveRecord based on their user_id in the session which is just as well the same as just using the ActiveRecord object, except in that case you reduce your code count a littlebit because then you don't need to update the session.
Maybe somebody else has better ideas but this is what comes up in my head.