zillablog - Comments

Gabriele Bartolini: Shoot The Automated Failure In The Head

nospam@example.com (Gabriele Bartolini) — Tue, 18 Sep 2012 09:04:51 -0400

I agree with you Robert. My opinion is that decisions should be driven by obtaining an acceptable Recovery Time Objective for manual failovers/switchovers. Most of the times, even with manual failover, if proper monitoring is in place, RTO is acceptable.

Laura Thomson: Root Cause of Success

nospam@example.com (Laura Thomson) — Fri, 22 Jun 2012 10:18:35 -0400

We do postmortems when things go right - not always but we have, especially for big things that go right. It's important to go over it and see what went right, and also know how it could go even better next time.

Javier Salado: Intrest free (technical) debt is risky

nospam@example.com (Javier Salado) — Tue, 07 Feb 2012 05:16:51 -0500

Hi Robert,

Tanks for your thoughtful interest in my latest post.

You are absolutely right about the underlying risk of any kind of debt. One should never neglect it.

My point by using the fiction scenarios was to highlight the fact that there is debt that cost you more on a daily basis that other. When you have extra money to return your debt you have to put it on the one that has more interest rate.

Okay, that can be argued too. Maybe you should mitigate the risk before. That heavily depends on the amount of debt, your exposure to the risk and how much is costing you today.

So, the bottom line is. Never neglect your debt and eliminate as much as you can with all the information at hand to set priorities.

Cheers,
J.

Anonymous: Checkpoints, Buffers, and Graphs

nospam@example.com () — Tue, 20 Dec 2011 10:49:50 -0500

thanks for the slides and the post.

Greg Smith: Checkpoints, Buffers, and Graphs

nospam@example.com (Greg Smith) — Sun, 27 Nov 2011 15:42:51 -0500

And the slides are up at http://www.2ndquadrant.com/en/talks/

Alvaro: Index pruning techniques

nospam@example.com (Alvaro) — Thu, 24 Nov 2011 11:42:54 -0500

You probably want array_agg instead of array_accum. That said, if you don't understand how to fix the query, it's unlikely that you'd be able to interpret the results either.

Jim Mlodgenski: Checkpoints, Buffers, and Graphs

nospam@example.com (Jim Mlodgenski) — Wed, 16 Nov 2011 17:11:42 -0500

For people in the New York area, Greg will be giving the same talk at the NYCPUG meeting tomorrow. Go to http://www.nycpug.org/ to RSVP. There are still a few spots available.

Robert Treat: Understanding Postgres Durability Options

nospam@example.com (Robert Treat) — Fri, 11 Nov 2011 18:23:56 -0500

Hmm, ISTR a problem with running non-full-page-writes with WAL based replication, though you could probably do this using something like Slony. The danger here is that I think you might be risking corruption even in non-crash situations. That might just be paranioa, but I don't think the non-full-page-writes code paths are used very often (and it's hard to think of a scenario where I would want to test it).

Robert Treat: Understanding Postgres Durability Options

nospam@example.com (Robert Treat) — Fri, 11 Nov 2011 18:19:32 -0500

I thought about mentioning synch rep, but I don't really see it as a pure durability play; imagine two synch rep'd servers where both have fsync off. (This isn't as horrible as it sounds). It does help with data persistence and availability, so it's probably worth mentioning.

Tomas: Understanding Postgres Durability Options

nospam@example.com (Tomas) — Thu, 10 Nov 2011 09:08:12 -0500

It's worth stressing out that the delayed commits (commit_delay/commit_siblings) don't trade durability for performance - it's rather latency vs. throughput. I.e. you can get higher throughput for higher latencies.

And I wouldn't say it's less granular than the synchronous_commit option - you can enable or disable it for each transaction IIRC, plus you can tune the number of required siblings (when there's less transactions in progress, it does not wait). Sure - when the transactions are idle for some reason or take very long to complete, it won't help.