__s

Every year I just say I want to improve my work life balance & work out more

Doesn't happen, but hey at least I'm being honest about what I'd like to improve

Or just order any macropad

I find it irritating with humans. "last but not the least" always distracts me as I then consider maybe the last item _is_ the least. & what is with everyone saying they want to "double click" into meeting items

you encode information in the token, this was a motivation for postgres to remove 32 byte cap on tokens: https://www.postgresql.org/message-id/508d0505-8b7a-4864-a68...

See from slide 26 https://www.pgevents.ca/events/pgconfdev2024/sessions/sessio... Jelte's a pgbouncer maintainer, video of a talk on this by him: https://www.youtube.com/watch?v=X-nCHcZ6vQU

Yes, https://www.pgbouncer.org/config.html#section-peers

SO_REUSEPORT[1] pretty much does all we want in kernelspace vs unnecessary userspace hop inbetween. These all run on same VM

1: https://lwn.net/Articles/542629

If it weren't for those bone spurs maybe that war wouldn't be so forgotten

B-roll

Silent execution of tremor was a pain in the ass trying to upgrade to nextjs 15 / react 19: https://github.com/tremorlabs/tremor/issues/148

Yes. & in the end my experience has been that you can write low latency code with gc, but only by expending more effort than it'd take to use manual memory management

Fable's spatial reasoning is much better. Over the weekend I had opus looking into a blank textbox issue[1] which it was spinning on for a few minutes, switching to fable immediately fixed

But yeah opus often the better workhorse given price gap

1: tying up loose ends testing https://github.com/HarbourMasters/Shipwright/pull/5838 (fix: https://github.com/HarbourMasters/Shipwright/pull/5838/chang...)

I've experienced the opposite: wishing I were dead so life wouldn't go on with me falling into just another glum existence. That at the emotionally present moment I snapshot it, preventing inevitable dullness that time moves on

Unfortunately here I am, life moves on, now I'm just wasting away on HN

Haha I'll be lucky if I can gather 2m & still have sacrificed much work life balance just because my type of stupid is an obsession

I have yet to see a program that silently handles allocation failures and doesn't crash

Postgres handles allocation failures

Sai is https://news.ycombinator.com/user?id=saisrirampur

Maybe we were saved by being acquired before hiring sales. Sai knew the problem & understood customers. He'd sometimes oversell a bit, but managed it: kept pulse of capacity for new development, would ask about how hard requested features were, would feel out customer intent & guide customer adapt to what was already there

When we had our pepepizza moment, there was an understanding that it wasn't going to work, took learnings of what would be involved there, but kept focus on improving what we already had

For kafka connector we had a design partner, I got to work with them directly. They wanted 30 microsecond message processing, so didn't want json. Original ask was flatbuffers. I decided to put message formatting into a scripting layer using gopher-lua. Spent a weekend getting flatbuffers working with lua (it was buggy, opened half a dozen PRs to flatbuffers repo which got ignored). It was clearly awful having to manage flatbuffer schema files & update scripts every time schema changed. But I had alternative already made: msgpack. Throughput needed work but addressed that by creating pool of lua interpreters

Overall I overworked myself (put my hands out of commission & spent months relearning how to type on split ergo colemak-dh), but I enjoyed the work. Team was very open with each other & when performance is your selling point there's an understanding that engineering quality needs to be maintained. Sure there were parts of the system I hated, & sometimes I'd try chip away at those

Hopefully that helps, hard to say the difference, but I really feel in my work that when customer has problem I'm part of conversation. Most recently there was talk of customer wanting cold data offloaded from postgres which is what inspired https://github.com/ClickHouse/pg_clickhouse/pull/298 where we get Postgres to do most the work

Raised problems trying to mix C++ into postgres extension, decided fix was to write clickhouse-c library to replace clickhouse-cpp, there was some doubt on team about value, but demonstrated value (https://github.com/ClickHouse/pg_clickhouse/pull/254) & I appreciate my colleagues not being afraid to change their mind

There's a level of trust where instead of being assigning tasks on a board I instead work on what I think is important based on information available. Nobody was asking for wal-rus, but I know my fleet

ClickHouse Cloud similarly took route of taking its time hiring sales. Better to have a small sales team that can work directly with engineering on quality leads than overwhelming everyone so that sales becomes the enemy. Guess the difference is agency. When engineering is involved in making commitments they're invested in delivering & there's push back so sales doesn't start hallucinating features

I did at peerdb

You don't need to be charitable, Snowflake laid off technical writers citing AI to replace them: https://snowflake.help/snowflake-layoffs-2026-technical-writ...

& ClickHouse has managed Postgres in open beta (which I work on)

I'm on 128GB ram strix halo, bought framework desktop for a few thousand CAD back when everyone was calling framework desktop overpriced

If you're running pg yourself I recommend pgbackrest. It doesn't run as a daemon, & it forks multiple processes for concurrency. But it's simple to run as archive_command & is light on resources outside concurrency

wal-g/wal-rus have higher throughput

tbf it took 4 years since PG15 support was added for me to fix remote BASE_BACKUP support & wal-g base backups being inconsistent on PG15+ (parameter typo had pg_backup_stop return before wal archived far enough for consistency)

https://github.com/wal-g/wal-g/pull/2262

but yes, this is young project, so fair take

indeed, wal-g actually started as a port of wal-e which was Python: https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-...

wal-g was a much larger improvement over wal-e. we're optimizing the margins here

in reality no, for the sake of the analogy, yes

Correct. We tune overcommit so postgres reliably returns out of memory. It becomes complicated to accurately tune overcommit for every AWS instance type. We configure GOMEMLIMIT/cgroups but those are about RSS. Outliers come together: instances running queries out of memory on our service tend to also be pushing other resource limits, causing wal-g & prometheus exporters to start having more erratic memory usage at the worst time

This helps on both ends of the cost spectrum. Large 64 core instances are where our heuristics fall off the most as variance increases, & tiny instances with 8GB of memory can use every 100MB of RSS we can get

no. but wal-g & wal-rus both have parallelism over wal-e. however are you more asking about handling build up of wal / vacuum prevention caused by long running transactions? those are up to postgres, archive command only keeps pushing wal so that when postgres is ready to get rid of wal it can. seems like your scenario wouldn't care much what the archiver is since wal should be shipped long before postgres is ready to get rid of wal

Is it really false? You can go on about survivorship bias but in the end a prerequisite is necessary for opportunity/chance

Can't win the lottery if you never buy any tickets

This is pretty much the case with every SQL dialect

They're not organized: you go into the yard, find the vehicle you're looking for, take the part out yourself, & they weigh it on the way out

https://www.andysautowreckers.ca they have a field of junk cars that people come in & harvest parts from

Seems like for airtightness you'd store utc alongside utc of when timestamp was stored alongside timezone