bonesmoses's comments

Version 3.6 is definitely after we introduced that functionality. It was, alas, rarely deployed though. Usually clients needed a consultant to put together a configuration for them, and most didn't bother.

There's an option in the Postgres configuration named "track_commit_timestamp" that does this automatically. It's required to be enabled when using LWW as the conflict resolution model. If there's a tie, the node with the highest node number wins.

I don't recall which customer you may have been, but the standard solution to that specific DDL issue with BDR is to use Stream Triggers to enable row versioning. One of the 2ndQuadrant customers used it extensively for multi-region cross-version app schema migrations that could last for months.

Essentially what that boils down to is you create stream triggers that intercept the logical stream and modify it to fit the column orientation by version. So during the transition, the triggers would be deployed to specific nodes while modifications are rolled out. Once everything was on the new version, triggers were all dropped until the next migration.

Spock doesn't have anything like that _yet_, but as you observed, being unable to use DDL replication significantly increases complexity, and tmux is a poor substitute.

You can't even run pgbench unaltered on CockroachDB, as simple table structures and indexes are fundamentally different there. It is in no way a compatible product, and never has been.

In Postgres, updates contain the entire row, including all column values. Since the Spock extension follows the "Last Write Wins" model by default, one row version will win, while the other is essentially discarded. This is assuming the update happened on each node _before_ the new value was synchronized over, or essentially simultaneously.

You can address this partially using a CRDT such as the Delta Apply functionality for certain columns:

https://docs.pgedge.com/spock_ext/conflicts

That will only work with numeric-type (INT, BIGINT, NUMERIC, etc.) columns, but effectively merges data so updates work cumulatively.

I'm not against using UUIDs, but it has to be done in a balanced manner. Normal numeric IDs for all surrogates, and then a UUID as an external lookup attribute. You push that externally for API calls, tokens, etc. so you don't have to worry about leaking sequential values, so it should be indexed. Otherwise, it's purely a lookup to key you into the JOIN chain for everything else.

That said, Now that UUIDv7 is available, switching to that should be a priority.

You might want to consider a different name, as there's already a pgcat project which appears to be a logical replication extension to augment native logical replication.

https://github.com/kingluo/pgcat

Right tool for the right job. Users in Tokyo won't be editing accounts for users in Austrailia. There's often a natural partition there where you can leverage the data locality with an eventual consistency basis safely.

Conflict-free Replicated Data Types (CRDTs) and column-level conflict resolution also largely address the issue with data merges and coarse counter systems. I'll just ignore the general design flaw there, considering these should be an insert-only ledger system rather than counters, because bad or naive implementations abound. I get that the application layer shouldn't necessarily have to coddle the database, given absolute ACID would resist non-ideal usage patterns.

I haven't played with the others, but I set up an 8-node CockroachDB and managed to get pgbench to run on it. I was clearly doing something wrong, because I wasn't impressed at the throughput even with very high client counts. From what I could see there, I was clearly being throttled by some mix of RTT and locking contention between the 3-node default consensus group. Supposing this is not problematic in non-overlapping shard locality, you still hit a hard performance ceiling when multiple clients interact with the same pool fragment.

I'll have to look at the others now.

LWW / LUW systems are a fine first approximation, but generally do not fulfill the strictest guarantees and desirable outcomes for a database without accounting for a lot of edge cases.

A good conflict management system will have that only as a default. Better ones will also provide mechanisms for overriding LWW in specific scenarios on a per table or even row basis depending on the in/out values from both nodes. The trick is building these conflict management rules so they're independently deterministic, or you'll end up with node divergence.

Normally we just do what you said, and strongly recommend interacting with sticky sessions, geographically disparate segments, etc., to prevent the problem before it happens. It's far easier to avoid a conflict than to correct it after the fact.

While a consensus model "fixes" this, it drastically cuts your throughput to a function of the latency of the most remote node in the quorum, essentially defeating the purpose of having a local Master node. Ideally you would reserve this for specific transactions that are sensitive in that they require absolute consistency regardless of incurred latency (See PACELC). And even this requires a distributed deadlock detector unless more than just the transactions are managed through the consensus layer.

BDR for example provides both of these models for the above reasons. Multi-Master is not an easy problem to solve, and requires a multi-faceted approach to even come close to something usable in a generalized scenario.

I had a very protracted DPDR experience start around when I was 12, and slowly dissipated over the course of a decade. I woke up one morning, and it was like I was slapped out of my body. It's like I was piloting a Me(ch) suit.

I wasn't seeing through my eyes. They were transmitting, with perceivable lag and some kind of acknowledged overlay, their sensory data. It's like being embedded in _extremely advanced_ and nearly seamless VR, but also hyper aware of the "nearly" part. It's like the Uncanny Valley effect, but directing it toward your own sensory system.

It doesn't feel quite real anymore, and you don't know why. So that's probably how I'd convey it. "You know the Uncanny Valley? Imagine everything you experienced felt that way."

It's uniquely awful.

Just the annoyance of having to itemize a receipt _to that granularity_ would annoy me enough to quit working at a company like that.

That's an excellent point. By opening up this can of worms, MySQL fans essentially get free reign to take shots at Postgres for flaws it still has for one reason or another. Perceived or genuine.

On the other hand, sometimes a good flamewar really gets the juices flowing and sheds valuable light on painful truths. Even Postgres can learn from being the butt of a few jokes.

Cross-column statistics are one of my favorites. The way Postgres 10 handles it is really a _huge_ advancement that addresses a painful edge case that has been around for ages.

https://blog.2ndquadrant.com/pg-phriday-crazy-correlated-col...

So far as the speed is concerned, we ran some tests a while back and it came back as nearly native performance when compared to interacting with a non-partitioned table:

https://blog.2ndquadrant.com/pg-phriday-dearly-de-parted/

Which is, almost ironically, going back to vocational training instead of standard Liberal Arts degrees. I triple-majored in Math, Physics, and Computer Science because I had to be there for the whole degree, so why not. But all I really needed, and all I use to this day, is the Computer Science portion.

We could probably eventually overhaul the system to that end, but I don't envy those trapped in the transition period.

As someone who went to that Cornell, I somewhat regret my decision. Sure you can cram in as much information as possible in that month, but long-term memory generally requires periodic refreshes. I've forgotten pretty much everything I learned there. :(

Isn't 30% is more than enough? If 3-4 people apply for a single position and 1-2 of them have a degree, then it's a fairly reasonable decision to ignore the other two.

And the ratios I've seen are far more than 3-4 applications per position.

Is it really a "reverence" though? When practically everyone and their dog has one, it's the new minimum.

This is in very specific neighborhoods due to gang activity for the most part. It's hardly an indicator of safety over the city in general.

I'm not entirely certain normalizing hyperbole makes sense here. There's a massive difference between ensuring children are safe and supported, and never letting them do anything without supervision or face any consequences up to and including when they go to college or join the workforce. There's an equally vast gap between taking eyes off a child for a few seconds, and outright neglect. Likewise, there's a universe of difference between basic precautions and the equivalent of a Safe Space (tm).

Yeah, I get that people are going to naturally jump to conclusions. Yet glossing over the minutiae is exactly how we got into the situation where everyone is jumping at shadows in the first place. Everyone's a rapist! Children are being mowed down in the streets! Drugs are everywhere! Never go outside! Anything else is literal child abuse! How dare you!

How does catering to social media because it might overreact fix that? How is that encouraging empathy? What makes this a "big problem?" Isn't relaxing our iron grip just a tiny fragment and rolling some of this hysteria back slightly do exactly that? Empathy for the situation instead of zealous indignation?