Greg Stark

Postgres provides a plethora of performance metrics useful for monitoring tools available through SQL. However monitoring a traditional relational database using modern observability tools presents some unique challenges.

Postgres's metrics can be extremely detailed and provide rich information about the relationships between the different database objects. However this requires custom SQL queries and the getting the right level of detail depends heavily on understanding style of architecture of the database schema. This kind of customization makes it difficult to deploy and maintain any dashboards, or alerts.

Even on a mundane level deploying an agent to interface through SQL introduces operational difficulty requiring additional custom work to coordinate the agent and database deploy and introducing many failure modes which can result in inaccurate metrics, no metrics, or even cause database outages.

I'm currently working on improving Postgres's support for modern observability tools and I have plans and challenges to talk about. Ideally I want to make things work smoothly out of the box without having each site have to write custom queries and design custom dashboards to get the right level of data for their database and adapt it to their deployment environment.

LLVM's Libfuzzer is uniquely suited for fuzzing components of client/server applications such as PostgreSQL. I'll present blockers preventing other tools such as AFL from being used effectively in such an environment and why Libfuzzer works much better for us. I can demonstrate (not a live demonstration!) the resulting Postgres module which presents an interface to call arbitrary SQL functions with fuzzed inputs.

Postgres documentation says "Code support exists for M32R and VAX, but these architectures are not known to have been tested recently."

Challenge Accepted! :)

Trying to get Postgres running on the VAX emulator simh started as a whimsical exercise in necrocomputing with no obvious benefit. No users were known and as far as we could determine no users had existed for at least 10 years. In the end it turned up two bits of inefficient code that was depending heavily on IEEE floating point where floating point math wasn't needed at all. It also turned up unexpected issues in the automatic configuration on machines with very limited memory and most suprisingly a NetBSD kernel bug.