You’re probably already running pgBadger to monitor your PostgreSQL logs. However, you’re probably not running it incrementally throughout the day. Most likely, you’ve setup a cron.daily job that runs pgBadger against yesterday’s log(s). And that’s great. Except when you get the dreaded “what just happened on the db?” email. Are you going to wait until tonight’s normal run of pgBadger to see what happened? Are you going to run a ‘one off’ pgBadger against today’s logfile and wait for it to process the entire log? Or are you going to copy the log off somewhere, edit it to cut it down, and then run pgBadger against this cut-down version (hoping you left enough in the log to see proper trending)?
read more
Partitioning in PostgreSQL can be a little daunting at times. In fact, you should probably just use pg_partman and be done with it. However, if you’re trying to learn, can’t use pg_partman, or are a masochist you’ll probably be following the docs and thinking ‘seriously? i have to create indexes on each child? why don’t they copy the indexes of the parent? why isn’t this easier?’. Here’s a little tip to make things slightly easier:
read more
UPDATE: My coworker Richard liked this write up, and Skytools, so much he threw together a demo script. You can get it here.
read more
While there’s absolutely nothing new in this blog"post"that isn’t covered by the wonderful docs I’ve been asked multiple times now by customers if we had some kind of ‘crib notes’ format for how to get replication up and running. And since I just had to set this up and document it for a customer, I figured I might as well"post"it so that I can simply point people to it in the future. So here we are.
read more