Looking at the file with changes https://github.com/postgres/postgres/blob/master/src/backend... , I have to say this source code repository is so well documented/commented and structured, I really gives you a huge trust in postgres to be used in your stack.
Important PostgreSQL 14 update to avoid silent corruption of indexes
11–20 of 101 posts
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#12Looking at the file with changes https://github.com/postgres/postgres/blob/master/src/backend... , I have to say this source code repository is so well documented/commented and structured, I really gives you a huge trust in postgres to be used in your stack.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#13Looking at the file with changes https://github.com/postgres/postgres/blob/master/src/backend... , I have to say this source code repository is so well documented/commented and structured, I really gives you a huge trust in postgres to be used in your stack.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
https://github.com/torvalds/linux/blob/master/kernel/sched/c...
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#14Looking at the file with changes https://github.com/postgres/postgres/blob/master/src/backend... , I have to say this source code repository is so well documented/commented and structured, I really gives you a huge trust in postgres to be used in your stack.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#15Earlier quoted context omitted.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
I get the impression that long files are culturally acceptable in systems-level C code. E.g., just a cherry-picked file from Linux: kernel/sched/core.c is over 11k lines. https://github.com/torvalds/linux/blob/master/kernel/sched/c...
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#16Earlier quoted context omitted.
File could definitely be broken up a bit. Over 5000 lines! Just a nitpick though.
Actually I don’t mind big files. It is simpler scanning through it or doing a quick search than if you had a bunch of smaller files. And 5000 lines is not awkward for most editors, especially as many editors have the ability to collapse functions.
As an example, making several related changes in very different parts of a file, where you need to cross-reference between them. The changes themselves might be small, but it’s a huge cognitive burden to alternate/iterate through them. I’d love to have a view which temporarily projects those targets as if they’re isolated files without changing the actual structure on disk. I’d love it so much I actually do this manually for a lot of tasks, creating temp files to prepare edits for related areas of code. But then I lose a lot of the benefits of tools which understand what’s being referenced. It would be great to just type a quick command (or click or whatever) to say “don’t refactor this function to another file, but let’s pretend you did, for a while”.
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#17Looking at the file with changes https://github.com/postgres/postgres/blob/master/src/backend... , I have to say this source code repository is so well documented/commented and structured, I really gives you a huge trust in postgres to be used in your stack.
Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#18Re: Important PostgreSQL 14 update to avoid silent corruption of indexes
#19It is noted in the post, I'll repeat it to be clear: This corruption can only occur _during_ a (re)index with CONCURRENTLY specified, on rows that are modified during the reindex operation, and only for that index. No other indexes are impacted, and an index can only be impacted when the updates on the table don't update indexed columns. Nevertheless, if you frequently run CIC, you could be having this issue -- right…
Everyone seems to be downplaying this corruption issue saying it only happens when x or y and it can be avoided by doing complex operation z but… if build anything that isn’t a toy or demo on Postgres you NEED to build indexes concurrently.
They shipped optimization to a feature to let indexes be built concurrently yet failed to perform thorough enough testing to ensure concurrent updates don’t disrupt the correctness of the index? Yikes, doesn't exactly make me confident in using any new Postgres features.
Further, there’s no workaround that wouldn’t cause a production outage due to requiring a table lock until they release the new build which is somehow not as soon as it’s available.
How are we not more alarmed by the impact of this?