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.

http://gouletpens.com

http://jetpens.com

http://nibs.com

Are decent places to start looking for more modern pens. Hope that helps.

0Thread HN

Bi-Directional Replication for PostgreSQL v1.0 10 years ago

Josh Berkus, core PostgreSQL member and currently employed by Red Hat seems to think they go well together. Here's some of his work:

https://www.youtube.com/watch?v=iruaCgeG7qs

https://github.com/jberkus/atomicdb

0Thread HN

Transaction ID Wraparound in Postgres 11 years ago

Happens. Glad you're back up and running, and best of luck with your new setup. =)

0Thread HN

Transaction ID Wraparound in Postgres 11 years ago

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.

0Thread HN

MySQL performance optimization: 50% more work with 60% less latency variance 11 years ago

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: