_rami_

This is the default in some countries, e.g. Italy in major cities :D

There's completely safe thermal paper in Germany by this company: https://www.oekobon.de/ There's a similar company in France, I forgot the name

Author here. Funny this ended up here again!

These days, we don't use this any more. First, because we now use primarily original Boca printers and are allowed to use the official drivers, and second, because we do 99% of printing from Android devices, where we also handle the protocol conversion ourselves, but it's a lot simpler without CUPS. Still, was a fun ride doing this back then!

(Author here) Interesting! How do you differentiate between a bot and a screenreader user? Both won't move their mouse, scroll, etc but only send a single click event

(Author here) Anything else than first-come-first-served requires strong identity to avoid people trying to get better chances with many entries into the pool, thus falling into the "sacrificing privacy" category

(Author here) Yes, every kind of lottery/raffle is a possible solution but only with strong identity verification to avoid double-entry and hence only with sacrificing privacy, as mentioned in the article.

pretix | Linux sysadmin | https://pretix.eu/about/de/job/ops | Heidelberg, Germany | Full Time | REMOTE (DE) | €57k+

Is there any source / data on that? I haven't noticed such a difference between our apps.

Thanks, that's great to hear! :)

Our CI rans our test suite against all of SQLite, MySQL and PostgreSQL which worked well enough that I can only remember one or maximum two bugs caused by this, but yes, wise words.

Sure, the main reason for this is that nearly all of our tests touch the database and operate on a comparatively high level, we have way more things in a fuzzy category between functional and integration tests than actual unit tests. This is of course a flaw in our test writing, but it's what we have right now ;)

> Also it's unclear from the article but why would the followers be so out of sync? Is there a really bad network? Especially if they set quorum writes on the master then at least 1 follower should always be up to date.

Yeah, I should have gone into more detail there. I'm talking about cases like after an outage when there is a lot to catch up with, or worse, if there are conflicting timelines (e.g. after a power outage) and synchronization stops working completely -- the broken follower will still answer queries and I've not yet found a simple way to monitor this condition.

Ouch. FTR, patroni does a similar thing, but instead of rm /var/lib/postgres it does a mv /var/lib/postgres /var/lib/postgres.bak.date ;)

It certainly is a future perspective for us, moving to all-postgres, but forcing every installation of pretix (an open source application) to go through this migration is not something we'll do overnight ;)

That's weird indeed (although I don't see any connections to a http: URL in the dev console). If someone else reports a similar problem, I'll just remove piwik alltogether.

Hi! :) do you explicitly see that HTTP URL or is it just a guess? I'm struggling to find it right now :(

Hmm, weird, cannot reproduce this in either Chrome or Firefox, with or without ad blocker. Anyone else having this problem?

We haven't in depth, as they only advertise with their sharding and distributed query features etc and less with their HA features (if that is even in Citus Community).

Sharding data is something we won't do before we absolutely need it, since disk capacity is not at all our constraint right now and our scaling problem isn't that its hard to serve many tenants at once, but we may need to be able to serve one tenant with very high concurrency the minute their tickets go on sale (which would only affect one shard on a usual sharding setup).

Are you using Citus for HA? Would love to hear your thoughts!

Sure, there are often problems differing between the databses. Our Travis CI configuration runs our test suite against all three different databases: https://travis-ci.org/pretix/pretix/builds/351704035

However, having SQLite at hand for local development/testing makes things easier.

In my experience, real-world concurrency issues (that you are talking about) are always hard to find in manual/automated testing, or do you have a good strategy of trying that?

I may add that our development setup has no external service dependencies, redis is optional as well. Of course, we wouldn't recommend that in production, but we're kinda proud that it's possible.

Me too, at times. Django makes it bearable though, and going forward we'll probably use more advanced features of PostgreSQL in places where we can fail gracefully or fall back to simpler behaviour on other databases.

Our development setup currently does not need Docker at all. In fact, it does not need a lot more than git and a recent Python version: https://docs.pretix.eu/en/latest/development/setup.html

I agree that this is an opinionated setup and I do see the value of a development setup that mirrors production closely.

(1) During testing, in-RAM SQLite databases are really fast and well capable of running tests in parallel. We have a test suite of ~2000 tests that currently needs ~4min to run on a modern notebook with four threads, so this matters.

(2) pretix is an open source project. If we'd only have a small number of developers in an in-house team, I wouldn't care at all. However, there are many people contributing small and large features and fixes to pretix, and many of them are drive-by contributions: People fixing a problem they just experienced and then leaving again. I want to make it easy for these people, even if they use operating systems where installing Docker first might be a hoop they do not want to jump through.

That said, deprecating MySQL at some point would also force all self-hosting users of pretix to go through all the steps we did here, so this wouldn't be viable in the short term.

No, we haven't. You are absolutely right that this would probably mitigate the deadlocks. However,

(1) the deadlocks/WSREP was a problem annoying us, while the query performance was a problem leading to real customer complaints, (2) as I see it right now, we would have needed to take complicated steps to ensure that all application nodes always connect to the same database node; just a hardcoded priority would probably not be enough, (3) a mechanism for (2) would likely make us loose more of the advantages of Galera, e.g. short failover downtimes

Hi, author/maintainer here, happy for any feedback or questions :)