Why are you not logging your DDL?

Last week I had yet another customer issue where "someone" had been issuing DDL statements in the database. And nobody knew who. Or why. But (surprise!) it broke things (and they weren't even running Slony!). There are two simple lessons to be learned from this:

In a production environment, arbitrary DDL statements are normally not run. If they are, you really need to look over your application design, because it's broken. Note that this does not include temporary tables. Also things like automating the creation of new partitions are also pretty normal. But the important thing there is that it's controlled and scheduled work, not arbitrary statements.

So, you'll want to keep track of your DDL. PostgreSQL provides a very simple and good way to do this. Set the configuration parameter log_statement='ddl'. The default value for this parameter is none, and there are also options for logging all DML and all statements period. But for a production environment, I find the ddl option to be very useful. So useful, in fact, that I'd consider it an installation bug in most environments if it's not set. So if this parameter is not set in your production environment, now is a good time to reconsider that decision.

The second thing to learn comes from the fact that once we tracked it down, it turned out that the DDL was issued from the application server. Which was running with superuser privileges. Now that's a much larger bug in the deployment, and a failure waiting to happen. There's a very simple lesson to learn from this: the application server should never run with superuser privileges. It should also not run with a user that has permissions to issue any DDL. This is simply the principle of least privilege - or at least principle of not insanely high privileges.

Yes, there are a number of application servers and frameworks that issue their own DDL as part of their ORM. The best way to handle them is, IMHO, to have them generate the SQL output and then manually apply that using a high privilege account. Because DDL should only be issued as part of upgrades and similar things, this should not be an issue. If the application server does not support this, a workaround is to give the application server DDL permissions during the upgrade only, and then take them away as soon as the upgrade is completed.

And yes, you should do this on your developer systems as well, and not just in production. Because if you only do it in production, you won't notice your bugs until you have deployed. It may seem like a lot of extra work to begin with, but it really is only a little extra work once you have got the procedures in place. And it can save you a lot of forensics work once something has happened.


Thanks for reminder. I also have to go for a production server in next 2 months.

Posted on May 4, 2009 at 19:31 by C P Kulkarni.

As ORMs become more powerful these sorts of issues will be more common. An ORM like Rails not only defines its own data model but also wants to push all the DDL through its Rails migrations. ORMS like that are starting to blur the line between app server and database, in favour of the app server.

Since there are more app developers than DBAs and customers ultimately buy applications rather than databases, I expect to see this trend growing and we in the database world will have to find ways to cope with it, as you show.

Posted on May 5, 2009 at 03:20 by Gordon Irish.

Set the configuration parameter log_statmeent='ddl'.

Misprint? log_statement?

Posted on May 6, 2009 at 12:05 by Pavel Golub.

Indeed. Thanks for pointing that out, fixed.

Posted on May 6, 2009 at 12:12 by Magnus.

For your rails sample it is not a big issue to run migrations with a different database connection than the application.

Of course this should be standard in rails but is not.

So the point is how to make app developers aware of the issue and provide means to separate DDL from normal database usage.

Posted on May 12, 2009 at 06:57 by Morus.


I speak at and organize conferences around Open Source in general and PostgreSQL in particular.



Stockholm PUG Oct 2020
Oct 27, 2020
Stockholm/Online, Sweden
Percona Live
Oct 21, 2020
Online, Online
Warsaw User Group
Jun 29, 2020
Virtual, Virtual
Postgres Vision
Jun 23-24, 2020
Online, Virtual
PGCon 2020
May 26-29, 2020
Online, Virtual
More past conferences