Hacker News Reader

At SurveySolutions we ended up with using shared lock during events readout from postgres. This solution is not the best, but good enough for us. https://github.com/surveysolutions/surveysolutions/blob/5bc9...

View on HN

Thanks for answering, I appreciate. I found good documentation in https://mariadb.com/kb/en/lock-in-share-mode/ but I am not sure how it works in Postgres: https://www.postgresql.org/docs/9.1/explicit-locking.html

It says "This mode protects a table against concurrent data changes" but it does not elaborate how. Is it similar in consequences to what MariaDB describes?

Basically Postgres SHARE lock will ensure that there is no active transaction in this table before executing query over table. This is a table wide lock and as I said it's not a best solution, as it will slow down a bit other events producers/consumers.

In our case - active data export process, will slow down a bit main application while reading new events.

Best solution would be using external tool to handle streams, like Event Store, Kafka or new RabbitMq Streams. But we prefer to stick with Postgres.

Reply on news.ycombinator.com