Kassandry
Re:Important women in CS who aren't Grace Hopper (2018)
on Tuesday February 11, 2020 @09:14PM (#22305138)
Audrey Tang as well. She's awesome.
Re:The Parker Vacumatic (2016)
on Friday April 19, 2019 @07:02AM (#19698502)
You could try things out with a Platinum Preppy for about 5 USD. Past that, a Pilot Metropolitan, or a Lamy Safari would be good entry level pens, in the 20 USD range. For 100-200 USD, you can get a very nice pen like the Pilot Custom Heritage 912, or a Pelikan M200. I'd recommend trying out the cheaper options first so you get an idea of what sorts of nibs you like.
Are decent places to start looking for more modern pens. Hope that helps.
Re:Bi-Directional Replication for PostgreSQL v1.0
on Friday August 12, 2016 @12:13PM (#12276768)
Josh Berkus, core PostgreSQL member and currently employed by Red Hat seems to think they go well together. Here's some of his work:
Re:Transaction ID Wraparound in Postgres
on Thursday July 23, 2015 @03:27PM (#9937916)
Happens. Glad you're back up and running, and best of luck with your new setup. =)
Re:Transaction ID Wraparound in Postgres
on Thursday July 23, 2015 @02:18PM (#9937500)
From their article:
"Additionally we had been running with far too much delay in vacuuming which meant lower load on the system, but more idle time in maintenance."
So, vacuum wasn't given the resources to keep up with their load, and it's not clear if they were supplementing with manual vacuums during quiet times. Nor was it clear when they started reacting, as PostgreSQL (also outlined in their documentation link), will start squawking about wraparound well before it shuts down, or the monitoring they had in place for whether or not autovacuum/vacuum was keeping up with the workload, or the number of locks their application was taking (locks can block autovacuum).
Adjusting the autovacuum settings by table will give you finer control over the postgresql.conf parameters to better match the workload for specific tables, as well.
Partitioning would have also helped make the actively written part of the table smaller, and older data could be vacuumed with VACUUM FREEZE, or deleted later. There are extensions to help make that easier.
https://github.com/keithf4/pg_partman
Josh Berkus of PgExperts has some great advice here:
https://dba.stackexchange.com/questions/21068/aggressive-aut...
So does Jim Nasby, here:
http://bluetreble.com/2014/10/postgres-mvcc-and-a-look-at-va...
Regarding monitoring, check_postgres.pl would give them an idea that their vacuuming settings needed adjustment sooner, or their application locking needed to be adjusted to not block autovacuum.
https://bucardo.org/check_postgres/check_postgres.pl.html#tx...
https://bucardo.org/check_postgres/check_postgres.pl.html#la...
https://bucardo.org/check_postgres/check_postgres.pl.html#lo...
It's easy to mention things after the fact, though, and it's good they got things up and running again for their customers.
Re:MySQL performance optimization: 50% more work with 60% less latency...
on Friday June 26, 2015 @10:43PM (#9788889)
It sounds like they really ran afoul of the stable page writes bugs that exist in Linux 3.2.31 to 3.9.
Thread discussing the bug and a test program to show the issue.
https://lkml.org/lkml/2012/10/9/210
Patch introducing the bug:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
Patch fixing the bug:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
It causes a huge dropoff in latency and throughput by causing all filesystems to block even when they don't need to.
In short, 3.2 is lethally bad in terms of database workloads.
SSL certificates restricted to 39 months validity after 1 April 2015 [pdf]
Re:Postgres 9.4 feature highlight: Indexing JSON data with jsonb data ...
on Monday November 17, 2014 @01:10AM (#8617060)