Disable editing of post during update
It sounds like you're running into a common deployment issue with Drupal: the fact that content and configuration reside in the same database. This generally puts a kink somewhere in most deployment strategies, as you start to run into issues whenever you have to merge existing user content (often a moving target) with upstream configuration changes.

Depending on how else you may have things set up, this may or may not involve drastic changes to your workflow, though this is the generally recommended solution for such issues. I'm not sure how much experience you have on these topics, so I'm going to break it down piece-by-piece for the benefit of anyone running into similar issues.

Dev/Test/Prod Workflow

Generally speaking, we have at least three servers in an optimal workflow. A "Development" server where our main version control repository lives (if you're not using one already, I highly recommend it!), a "Staging" server where we run our last rounds of acceptance testing and start adding default content, and a live "Production" server where everything is served to the end user.

Dev/Test/Prod in Drupal

As mentioned above, the fact that the database contains both content and configuration makes things quite messy. It's difficult to check a database into revision control, it makes configuration much less portable, and most attempts to decouple content and configuration are met with frustration (as with locking out certain privileges while making major updates to the site).

The adage "configuration moves forward, content moves backward" through the dev/stage/prod workflow still holds true as best practice with Drupal. We want to put as much configuration into code as possible, removing it from the database in an effort to decouple the two. This way, we can push features forward through the workflow as normal, and then take content from the live site and pull it back to dev when needed, without getting in the user's way.

Moving Configuration to Code

How do we move configuration to code, though? The Features module allows you to export the configuration of most popular modules to code as "feature modules"--in fact, anything that implements CTools Exportables is fair game. You could even add your own hooks to these exported feature modules and bundle them in an installation profile for one-click deployment (they're still just modules!).

In the rare cases where you can't achieve the desired functionality using Features alone and absolutely must hack at the database, you can do so through a custom module or an existing exported feature, using hook_install() and hook_uninstall(). hook_update_N() can be used for incremental updates, but remember to update hook_install() to reflect the same changes as well!

Moving Content

If required, content from staging can also be pushed to live using a solution like the Deploy module. This way, you can push updates from dev to staging, and then use maintenance mode on staging only when polished functionality is being pushed forward from Dev. You could also use it to push content from your live site back to the Dev server, to ensure that you always have easy access to the latest live content.

That said, now that configuration has been stripped out from the database, it becomes much easier to just move the database around as a content store, rather than a hodge-podge of content and configuration.

In Closing

This is a difficult and long-standing problem in Drupal, and doesn't have a quick fix, though I've used the above workflow on several projects with a high degree of success. I'd be happy to clarify any parts of my answer.