The 20th of April I was supposed to give the pgchameleon’s talk at the Pycon 9. However personal issues prevented me to come to Florence. This post is an explanation and an apology for the pycon 9 attendees and organisers.
What follows is the synthesis of several years of frustration. Before you start reading please note that the things written in the dark age section do not apply for the high end environments like Oracle. That’s mostly because starting an Oracle project without a DBA on board is an interesting and creative way to get bankrupt in few months. Obviously things evolves and maybe in the next decade my Oracle fellows will join me in this miserable situation.
2.4 The background writer Before the spread checkpoints the only solution to ease down the IO spike caused by the checkpoint was to tweak the background writer. This process were introduced with the revolutionary PostgreSQL 8.0. The writer, as the name suggests, works in the background searching for dirty buffers to write on the data files. The writer works in rounds. When the process awakes scans the shared buffer for dirty buffers.
The failure is not an option. Despite this statement is quite pretentious is also the rule number zero of any decent DBA. The task failure, should this be a simple alter table or an emergency restore, is not acceptable. The database is the core of any application and therefore is the most important element of the infrastructure. In order to achieve this impossible level, any task should be considered single shot.
Finally I finished the first volume of the PostgreSQL book administration. The book is free to download on slideshare or, if you want the hard copy there is the button to order on lulu.com. I’ll build an ebook version in the next days and I’ll make it available on amazon’s kindle and the kobo. I hope this book will spread the knowledge on PostgreSQL. Anyway, I’ve not finished. I’ve already started a second volume and a manual for the developers willing to learn the noble art of the SQL writing.