Trying to restore a Mountain Lion caldav.sql into a fresh/clean Mavericks installation

Question

Call me cynical, but upgrades and Migration Assistant were never my thing. I'm starting to experiment with migrating some of my Mountain Lion OS X Servers to Mavericks.
Under OS X Server 2.2.x (Mountain Lion), I had a script that would individually backup the postgres_server databases, caldav, collab, device_management, etc.
I'm now working with a clean Mavericks installation and trying to restore the caldav db. Through the help of ~morgen, I've worked out that caldav seems to have its own postgres instance and I can see and view the fresh caldav database there:
/Applications/Server.app/Contents/ServerRoot/usr/bin/psql -U caldav -h /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9/ caldav
So, I backed that up before proceeding with:
/Applications/Server.app/Contents/ServerRoot/usr/bin/pg_dump -U caldav -h /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9/ -c caldav | gzip -c > /Library/Server/Backups/PostgreSQL/caldav.sql.gz
And then tried to use dropdb to drop it, so I could use createdb to re-create it and then use psql to suck in my Mountain Lion backup. The three intended commands in order would have been:
/Applications/Server.app/Contents/ServerRoot/usr/bin/dropdb -U caldav -h /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9/ caldav
/Applications/Server.app/Contents/ServerRoot/usr/bin/createdb -U caldav -h /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9/ caldav
/Applications/Server.app/Contents/ServerRoot/usr/bin/psql -U caldav -h /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9/ -d caldav < /Library/Server/Backups/PostgreSQL/caldav.sql
HOWEVER.... the first command failed:
dropdb: database removal failed: ERROR:  database "caldav" is being accessed by other users
DETAIL:  There is 1 other session using the database.
Interestingly, even though neither Calendar nor Contacts server are running, there's quite a bit running under _calendar:
_calendar         656   0.0  0.1  2471756   4412   ??  Ss    6:53pm   0:00.03 postgres: caldav caldav [local] idle                         
_calendar         651   0.0  0.0  2471120   2228   ??  Ss    6:53pm   0:00.11 postgres: wal sender process caldav [local] streaming 0/422E020                         
_calendar         650   0.0  0.0  2460732   2216   ??  S     6:53pm   0:00.07 /Applications/Server.app/Contents/ServerRoot/usr/bin/pg_receivexlog -h /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9 --no-password --directory /Library/Server/Calendar and Contacts/Data/Database.xpg/backup --verbose
_calendar         649   0.0  0.0  2491744   1496   ??  S     6:53pm   0:00.02 /usr/sbin/distnoted agent
_calendar         646   0.0  0.0  2465500    652   ??  Ss    6:53pm   0:00.19 postgres: stats collector process                            
_calendar         645   0.0  0.0  2465500    416   ??  Ss    6:53pm   0:00.02 postgres: archiver process                            
_calendar         644   0.0  0.0  2470988   2460   ??  Ss    6:53pm   0:00.12 postgres: autovacuum launcher process                            
_calendar         643   0.0  0.0  2470856    560   ??  Ss    6:53pm   0:00.06 postgres: wal writer process                            
_calendar         642   0.0  0.0  2470856   1240   ??  Ss    6:53pm   0:00.09 postgres: writer process                            
_calendar         641   0.0  0.0  2470856   1056   ??  Ss    6:53pm   0:00.01 postgres: checkpointer process                            
_calendar         639   0.0  0.0  2455256    400   ??  Ss    6:53pm   0:00.01 postgres: logger process                            
_calendar         638   0.0  0.1  2470856   5272   ??  S     6:53pm   0:00.08 /Applications/Server.app/Contents/ServerRoot/usr/bin/postgres_real -c listen_addresses= -k /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9 -c shared_buffers=105 -c max_connections=70 -c standard_conforming_strings=on -c log_lock_waits=TRUE -c deadlock_timeout=10 -c log_line_prefix=%m [%p]  -c logging_collector=on -c log_truncate_on_rotation=on -c log_directory=/var/log/caldavd/postgresql -c log_filename=postgresql_%w.log -c log_rotation_age=1440
_calendar         636   0.0  0.0  2492336   2832   ??  S     6:53pm   0:00.04 /System/Library/PrivateFrameworks/TCC.framework/Resources/tccd
_calendar         634   0.0  0.2  2472760  16104   ??  S     6:53pm   0:02.17 /usr/bin/python /Applications/Server.app/Contents/ServerRoot/usr/bin/xpostgres -c listen_addresses= -k /var/run/caldavd/ccs_postgres_3d403b3009fe0c830944d87bd751fbe9 -c shared_buffers=105 -c max_connections=70 -c standard_conforming_strings=on -c log_lock_waits=TRUE -c deadlock_timeout=10 -c log_line_prefix=%m [%p]  -c logging_collector=on -c log_truncate_on_rotation=on -c log_directory=/var/log/caldavd/postgresql -c log_filename=postgresql_%w.log -c log_rotation_age=1440
_calendar         630   0.0  0.0  2471388    900   ??  Ss    6:53pm   0:00.20 /sbin/launchd
So, how can I gently get this mystical one user off of the DB in order to do this? OR, how can I start up calendar in such a way that this mythical user is not connected?
If I unload this job:
launchctl load /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/org.calendarserver.agent.plist
I can no longer access the postgres instance in order to drop and create the db.
Any other ideas / suggestions / solutions?

Answer 1

If you knew your sql, I don't think it would be insurmountable to pull apart the full dump.
As to the upgrades in place, here's some of the output in caldav's error log every startup:
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Beginning database schema check.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Required database key VERSION: 24.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Actual database key VERSION: 24.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Schema version check complete: no upgrade needed.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Database schema check complete.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Beginning database addressbook data check.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Required database key ADDRESSBOOK-DATAVERSION: 2.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Actual database key ADDRESSBOOK-DATAVERSION: 2.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Addressbook data version check complete: no upgrade needed.
2013-12-02 21:29:02+1000 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Database addressbook data check complete
To be clear, I don't believe its Server.app. Each of these services stores its schema version IN the database and its checked every startup, and it would appear, that each service knows how to perform that upgrade at each startup.