"I didn't fly across the Atlantic to... Of course I did"
I found a few earlier this year and I was going to file a bug so I did some research to find out this is a known and expected behavior.
If the computer say reads stubborn as stubbum, the smaller dictionaries are the ones that have cross checked and filtered those out. The insane ones do not. It's a good name. "Lack of sanity checks"
Here's an example word I found, "suabilities". You'll find it only on wordlist sites that used this wordlist and I guess, now here.
Does anyone know if there's a technical limitation to nested virt on EC2 or if it's just so people use .metal? I know Azure recently (1-2 years?) started offering it.
This has been a really elegant and low-complexity way to get distributed pubsub without the complexity of running a distributed erlang cluster (which seems a lil bit painful in a K8S+Continuous Deploy world)
There -are- some big downsides to be aware of though.
1. You can't use PgBouncer w/ LISTEN/NOTIFY. This has been really painful because of the high memory overhead of a pgsql connection + elixir keeping a pool of open pgsql connections. The tried and true method of scaling here is to just use PgBouncer. We've kicked the can on this by vastly over-provisioning our pg instance, but this has cost $10s of thousands on the cloud. Of course, it's solvable (dedicated non-pgbouncer connection pool just for LISTEN/NOTIFY, for example), but painful to unwind.
2. The payload has a fixed size limit (8KB, IIRC). This has bitten us a few times!
Even though I really like pg_notify, I think that if I were starting over, I'd probably just use Redis Pub/Sub to accomplish the same thing. Tad bit more complex if you're not already running Redis, but without the downsides. (Of course, w/ Redis, you don't get the elegance of firing a notification via a pg trigger)
function software_listen(channel, callback):
if not channel_listened(channel):
sql("LISTEN " + channel)
listeners[channel].append(callback)
function on_message(channel, data): for listener in listeners[channel]
listener(channel, data)
function unlisten(channel, listener): listeners[channel].remove(listener)
if len(listeners[channel]) == 0:
sql("UNLISTEN " + channel)
Here's the actual go implementation we use:https://gist.github.com/ColinChartier/59633c1006407478168b52...
(Okay, so apparently client ID isn't user ID, but app ID. Explains a lot.)
Could I conceivably put 200 messages per second through a Postgres queue given a big enough RDS instance?
Wondering if we don’t really need to move to Kafka at work…