Are you using `walg wal-receive` for streaming? As far as I can tell, that command will wait for the full wal segment before it pushes anything to storage. I don't see any way to stream wal records continuously in wal-g.
I went through quite the hassle to get the app's oauth scopes approved with Google so that it can keep your subscriptions up-to-date as you add or remove YouTube channel subscriptions.
Here's how we did it at OneGraph (RIP), where we not only upgraded versions without downtime, but we also moved hosting providers from GCP to Aurora without downtime.
1. Set up logical replication to a new database server. We used https://github.com/2ndQuadrant/pglogical, but maybe you don't need that any more with newer versions of postgres?
2. Flip a feature flag that pauses all database queries and wait for the queue of queries to complete.
3. Wait for the query queue to drain and for replication to catch up.
4. Flip a feature flag that switches the connection from the old db to the new db.
5. Flip the flag to resume queries.
It helped that we were written in OCaml. We had to write our own connection pooling, which meant that we had full control over the query queue. Not sure how you would do it with e.g. Java's Hikari, where the query queue and the connection settings are complected.
We also had no long-running queries, with a default timeout of 30 seconds.
It helped to over-provision servers during the migration, because any requests that came in while the migration was ongoing would have to wait for the migration to complete.
I'm impressed. I asked it "How much is a flight from San Francisco to the rapid & blitz tournament over Christmas?" and it figured out which tournament I was talking about and showed me ticket prices.
A few ideas to improve the schema based on looking at the examples:
1. Make `globalId` part of a "Node" interface that all of the types implement. This will work better with tooling like Relay (used for refetching and caching). It will also let you add a `node` field that can be used to fetch any node in the graph.
2. Make the sort input an enum so that you have `sort: TITLE_DESC` instead of `sort: {by: TITLE, order: DESC}`.
3. Implement the connection spec instead of returning a list of items: https://relay.dev/graphql/connections.htm. This will let you add pagination data to the field and other useful info like totalCount.
4. Spin up a postgraphile instance with the `@graphile-contrib/pg-simplify-inflector` and `postgraphile-plugin-connection-filter` plugins and copy everything they do.
Might be better to redirect to the news.ycombinator.com instead of google.com. I'd be less likely to notice that, especially if I opened it in a background tab.
But maybe that's the kind of criticism he was trying to avoid in the first place!
According to the article, they likely are getting severance.
Those affected will gain access to the company’s “generous severance philosophy” and “a talent hub to allow them to opt-in to receive additional support services.” (The details surrounding the severance package are unclear, but some affected workers on Blind alleged they would receive two months worth of base pay; a representative from Coinbase did not provide further comment.)
At the end of the video you linked, she accuses the author of The Star Builders of "only briefly mention[ing] the total energy gain and never giv[ing] a number".
I had just started the book when I watched her video, and I counted four separate times where he did mention total energy gain. In one chapter (pg. 142 in my kindle edition), he quotes from a source who lays out the distinction she claims people in fusion research want you to be confused about:
Like First Light Fusion, Tokamak Energy is much more interested in power production than energy breakeven. "Achieving a of one is a scientific goal," Jonathan Carling continues, "but it's nowhere near enough to produce commercial energy, which requires a Q [in the region] of tens." As mentioned previously, Q is the ratio of fusion power out to heating power in. His strong view is that unless other star builders have a credible plan to get to factors of twenty or thirty more power out than they put in, then they're in the science game and not the fusion energy game.
It's not the benchmark that's unethical. The unethical part is leaving up the original claim without adding a correction or a note that addresses the problems Fastly found with the benchmark.
Cloudflare's blog post still says, in bold, "Cloudflare Workers is 196% faster than Fastly’s Compute@Edge based on the time to first byte from the tests we ran on 50 nodes using Catchpoint’s data from across the world".
It is unethical to leave that up after Fastly pointed out core issues with the benchmarking, like using a free tier that was rate-limited.
My experience working at tech companies is that the tech lead, or anybody at the company, can post in an internal message board or slack to ask "what's up with this weird clause in our ToS" and expect an explanation.
It's nice that eastdakota responded here, but he had two weeks since the original tweet thread from Fastly's VP of Eng calling out the problems with their benchmarking. They didn't respond or retract the blog post in those two weeks.
As a cloudflare shareholder (and a fastly shareholder), I want Cloudflare to act ethically and either retract the blog post or issue a correction.
It has been two weeks since Fastly's VP of Eng called out your ToS and errors in your benchmark in her original tweet thread [1]. I would hope that Cloudflare would have a better response than this that directly addresses Fastly's claims.
Are you going to remove the ToS clause or issue a correction on the blog post?
This is just an illustrative example. I used NPM because it doesn't require any authorization. We also support proper subscriptions for NPM that listen to their couchdb change feed.
It's supposed to resemble a mac app window. I can add a setting to remove it if you like. Email me at [email protected] and I'll let you know when it's available.
https://github.com/dwwoelfel
https://twitter.com/danielwoelfel
YC Badge: 0x9e3313e5bd4204ba554c8615b35b4d99d089d31d