When managing production servers running critical services like PostgreSQL, the apt-get upgrade command requires careful consideration. Unlike development environments, production systems demand stability above all else.
Ubuntu's package management system provides several tools to balance these needs:
# Check available updates without installing
sudo apt-get update
sudo apt list --upgradable
# View changelog for specific package
apt-get changelog postgresql-9.2
Ubuntu categorizes updates into different types, which affects their urgency:
- Security updates (marked as such in apt output)
- Bug fixes
- Feature updates
For production PostgreSQL servers, implement this cautious approach:
# First, create a maintenance window and backups
sudo -u postgres pg_dumpall > /backups/full-pre-upgrade-$(date +%F).sql
# Test the upgrade process on a staging server first
sudo apt-get update
sudo apt-get upgrade --dry-run
# For security updates only
sudo unattended-upgrade --dry-run -d
These packages deserve extra caution during upgrades:
postgresql-common
libpq5
postgresql-9.2
openssl
linux-image-generic
Implement these safeguards to minimize risk:
# Hold specific packages from upgrading
sudo apt-mark hold postgresql-9.2
# Configure unattended security updates only
sudo dpkg-reconfigure -plow unattended-upgrades
Always verify system health post-upgrade:
# Check PostgreSQL status
sudo systemctl status postgresql
# Verify database connections
psql -U postgres -c "SELECT version();"
# Monitor system logs
tail -f /var/log/postgresql/postgresql-9.2-main.log
Postpone upgrades in these scenarios:
- During peak business hours
- When major database operations are scheduled
- Before important application releases
- When the update includes major version changes
For more controlled updates, consider Docker:
# Sample Dockerfile for PostgreSQL
FROM postgres:9.2.4
RUN apt-get update && \
apt-get upgrade -y && \
rm -rf /var/lib/apt/lists/*
When managing an Ubuntu 12.04.2 server running PostgreSQL 9.2.4 with live production data, the apt-get upgrade command presents a classic sysadmin dilemma. The notification "4 packages can be updated. 4 updates are security updates." appears frequently, demanding attention.
Not all updates are created equal. Here's how to inspect pending updates before applying them:
apt-get update
apt list --upgradable
Critical security updates (marked as [security]) typically warrant immediate installation, while other updates may require staging. PostgreSQL-specific packages deserve special attention:
apt-get upgrade -s | grep postgres
Database servers require more caution than web servers due to:
- Potential schema compatibility issues
- Connection pooling impacts
- Shared library dependencies
For mission-critical databases, consider this upgrade workflow:
# Create a maintenance window
sudo service postgresql stop
# Take a full backup first
pg_dumpall > /backups/pre-upgrade-$(date +%F).sql
# Perform dry-run first
sudo apt-get upgrade -s
# If everything looks safe
sudo apt-get upgrade
sudo service postgresql start
For security-conscious environments that prioritize stability:
# Security updates only
sudo apt-get --only-upgrade install $(apt-get upgrade -s |
grep "^Inst.*security" |
awk '{print $2}')
Or implement unattended-upgrades for security patches only:
sudo apt-get install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# Configure to only install security updates
Always verify database functionality after upgrades:
# Check PostgreSQL status
sudo -u postgres psql -c "SELECT version();"
# Verify connections
sudo netstat -tulnp | grep postgres
# Test sample queries
sudo -u postgres psql -c "SELECT * FROM pg_stat_activity;"
Postpone upgrades during:
- High-traffic periods
- Major business events
- When backup systems aren't fully operational
For complex environments, consider testing upgrades on a staging server first:
# Clone production to staging
pg_dump -h production.db -U postgres dbname | psql -h staging.db -U postgres dbname